fix(dev): un premier lancement qui echoue le dit, et se rattrape - #57
Merged
Conversation
Le premier lancement de dev.sh est mort pendant postCreateCommand, sur
npm ci. Le message n'etait ni dans la sortie du script ni dans celle de la
CLI, mais dans ~/.npm/_logs du conteneur : spawnSync .../esbuild/bin/esbuild
ETXTBSY. Le postinstall d'esbuild pose un lien dur vers le binaire de
plateforme que npm vient d'extraire puis l'execute, pendant que la phase
reify de npm peut encore tenir cet inode ouvert en ecriture -- et Linux
refuse d'executer un fichier ouvert en ecriture. C'est une course entre deux
morceaux de npm, elle ne dit rien du package-lock.json, et elle frappe un
volume web/node_modules NEUF : le premier lancement d'un contributeur.
post-create.sh retente donc npm ci une seule fois, et seulement si la sortie
nomme ETXTBSY. Tout autre echec -- un lock desynchronise au premier chef --
sort a la premiere tentative, ce qui garde a `ci` le caractere deterministe
que 14.1 lui demande.
Le second defaut est le plus grave, et il survit a la panne : la CLI
n'execute postCreateCommand qu'a la CREATION du conteneur. Le conteneur a
moitie prepare reste en place, le devcontainer up suivant repond
{"outcome":"success"} sans rien preparer, et dev.sh annonce alors
« Poste pret » sur un web/node_modules vide. dev.sh et dev.ps1 nomment
desormais la sortie de secours au moment ou ils echouent
(--remove-existing-container), portee des deux cotes selon la regle de
report du 10/08/2026, et handbook/getting-started.md la porte aussi.
Deux bancs tiennent les deux moities, rouges avant le correctif. Les deux
branches du rattrapage sont exercees avec un faux npm : echec ETXTBSY, deux
appels et sortie 0 ; echec de lock desynchronise, un appel, aucune reprise,
sortie 1. Conteneur et volume node_modules detruits, sh dev.sh rejoue de
zero : sortie 0. make test vert dans le conteneur neuf -- 3 135 tests verts,
10 ecartes, 0 echec -- et make front-check a 80 585 o gzip.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
La panne
dev.shmeurt pendantpostCreateCommand, surnpm ci. Le message n'est ni dans la sortie du script ni dans celle de la CLI, mais dans~/.npm/_logs/…-debug-0.logdu conteneur :Le postinstall d'esbuild pose un lien dur vers le binaire de plateforme que npm vient d'extraire, puis l'exécute — pendant que la phase
reifyde npm peut encore tenir cet inode ouvert en écriture, et Linux refuse d'exécuter un fichier ouvert en écriture. Course entre deux morceaux de npm : elle ne dit rien dupackage-lock.json, et elle frappe un volumeweb/node_modulesneuf, c'est-à-dire le premier lancement d'un contributeur.Le second défaut, plus grave, qui survit à la panne
La CLI n'exécute
postCreateCommandqu'à la CRÉATION du conteneur. Le conteneur à moitié préparé reste en place, ledevcontainer upsuivant répond{"outcome":"success"}sans rien préparer, etdev.shannonce « Poste prêt » sur unweb/node_modulesvide. Mesuré, pas déduit.Ce que fait cette branche
post-create.shretentenpm ciune seule fois, et seulement si la sortie nommeETXTBSY. Tout autre échec — un lock désynchronisé au premier chef — sort à la première tentative :cireste déterministe (§14.1).dev.shetdev.ps1nomment la sortie de secours au moment où ils échouent (--remove-existing-container), portée des deux côtés selon la règle de report du 10/08/2026.handbook/getting-started.mdla porte aussi, pour qui lit avant de se cogner.TestThePostCreateScriptRetriesNpmCiOnTheETXTBSYRaceetTestBothDevScriptsSayHowToRedoAFailedPreparation.Vérification
npm, branche ETXTBSY : sortie 0, 2 appels, message de reprise imprimé.npm, lock désynchronisé : sortie 1, 1 appel, aucune reprise.openscale-node-modules-…détruits,sh dev.shrejoué de zéro : sortie 0.make testdans le conteneur neuf, deux passes,boundaryetdepscompris : 3 135 verts, 10 écartés, 0 échec.make front-check: 80 585 o gzip, 71,5 % du budget.mkdocs build --strictvert.Ce qui n'est PAS fait
npm cisur volume vide et cache npm froid, tous verts. Le correctif s'appuie sur le journal de la panne réelle et sur unnpmbouchonné.dev.ps1n'a pas été exécuté, faute de Windows : il n'est qu'analysé pardeploy/powershell_test.go.--remove-existing-containerexiste encore dans une version future de la CLI : l'option est lue dans l'aide de la 0.88.0.