La CI Windows tourne en séquentiel : la cause, pas les symptômes - #6
Open
pymenvert wants to merge 1 commit into
Open
La CI Windows tourne en séquentiel : la cause, pas les symptômes#6pymenvert wants to merge 1 commit into
pymenvert wants to merge 1 commit into
Conversation
Publier la 2.1.1 a demandé quatre passages de CI Windows, avec quatre échecs sur quatre tests DIFFÉRENTS de champ3d.test.js — et pas un seul défaut dans Cascade : - l'ordre 3D relevait 3 barres sur 4 (fenêtre à 80 ms de marge) - 46 tests « cancelled », fail 0 (Edge pas démarré en 20 s) - écart-type du bruit divisé par deux (mesure avant l'établissement du champ) - deux barres confondues qui diffèrent (relevés décalés dans le temps) Les trois premiers sont corrigés à la source. Le quatrième a suffi à montrer qu'on courait après les symptômes : jamais le même test, jamais une seule fois en local, et il y en aurait toujours eu un cinquième. La cause est commune. `node --test` lance autant de fichiers en parallèle qu'il y a de cœurs, et chaque fichier démarre de VRAIS serveurs Cascade — parfois un navigateur. Sur cette machine de développement, 16 cœurs : ça tient. Sur un runner GitHub, 2 ou 4 : tout se dispute la machine, et des tests qui mesurent une grandeur qui évolue dérivent. D'où des échecs au hasard, impossibles à reproduire là où on les corrige. Le passage Windows tourne donc en `--test-concurrency=1`. Plus rien ne se dispute la machine. Mesuré ici : 310 s en séquentiel contre ~100 s en parallèle, d'où le délai du job porté de 10 à 30 minutes — un runner est plus lent, et ce passage a pour rôle d'attraper ce qui est spécifique à Windows, pas d'aller vite. ⚠ C'est un contournement honnête, pas une correction : il donne aux tests des conditions saines, il ne les rend pas robustes. Le passage Ubuntu, lui, tourne toujours en parallèle et reste exposé. Ce qu'il faudrait vraiment faire est écrit dans docs/reste-a-faire.md : que ces tests relèvent leurs valeurs au même instant logique, au lieu de deux moments successifs. 346 tests, 0 échec, 0 annulé, 0 ignoré — vérifié en séquentiel ET en parallèle.
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.
Objectif
Publier la 2.1.1 a demandé quatre passages de CI Windows, avec quatre
échecs sur quatre tests différents de
champ3d.test.js— et pas un seuldéfaut dans Cascade :
fail 0Les trois premiers ont été corrigés à la source (#5). Le quatrième a suffi à
montrer qu'on courait après les symptômes.
La cause, enfin identifiée
node --testlance autant de fichiers en parallèle qu'il y a de cœurs, etchaque fichier démarre de vrais serveurs Cascade — parfois un navigateur.
mesurent une grandeur qui évolue dérivent
D'où des échecs au hasard, impossibles à reproduire là où on les corrige.
Le changement
Le passage Windows tourne en
--test-concurrency=1, et le délai du job passe de10 à 30 minutes.
Mesuré ici : 310 s en séquentiel contre ~100 s en parallèle. Un runner étant
plus lent, la marge est nécessaire — et ce passage a pour rôle d'attraper ce qui
est spécifique à Windows, pas d'aller vite.
Vérifications
npm test(parallèle)npm test -- --test-concurrency=1Ce que ça ne fait PAS
⚠ C'est un contournement honnête, pas une correction. Il donne aux tests des
conditions saines, il ne les rend pas robustes. Le passage Ubuntu tourne
toujours en parallèle et reste exposé.
Ce qu'il faudrait vraiment faire est écrit et daté dans
docs/reste-a-faire.md:que ces tests relèvent leurs valeurs au même instant logique, au lieu de deux
moments successifs. C'est ce décalage, et lui seul, qui produit les écarts.