[infra] Chaîne d'intégration : le job du tableau de bord échoue un tiers du temps sur un délai réseau non borné

olivier commented

2026-09-04 09:07:46 +00:00

Member

Exigence couverte : ENF-11 — chaîne d'approvisionnement
Épreuve servie : EC03 · CI/CD et qualité

Ce qu'on veut obtenir

Suite du #133, qui a réuni les jobs et posé les caches. Le job Python en a
profité : 124–129 s, stable, aucun échec. Le job « Tableau de bord » non.

Mesuré sur les treize dernières exécutions de ci.yml (API actions/tasks) :

Job	Durées
Python — qualité, tests, dépendances	124–129 s, 0 échec sur 13
Tableau de bord	26 · 65 · 89 · 238 · 256 · 317 · 322 s, et 5 échecs sur 13, tous à 433–435 s
Contrôles statiques, secrets	3–5 s
Total `ci.yml`	158 s → 688 s, médiane ≈ 6 min

develop est actuellement rouge sur ce job (exécution #240, échec à 433 s).

Chronométré en local sur services/dashboard (244 paquets, 120 Mo) :

npm ci  (cache npm vide) ........  5,9 s
npm ci  (cache npm chaud) .......  0,8 s
vitest run (42 tests) ...........  1,9 s
vite build ......................  0,6 s
npm audit --audit-level=high ....  > 4 min, tué
   idem --fetch-timeout=30000 --fetch-retries=1 .... 12,5 s

Le coût n'est donc pas dans npm ci, contrairement à ce que le journal laisse
croire. Quatre causes, distinctes :

npm audit n'est pas borné. fetch-timeout vaut 300 000 ms par défaut,
fetch-retries 2, et aucun .npmrc n'est versionné. Les échecs se massent à
433–435 s : la signature d'un délai avec réessais, pas d'un travail à durée
variable. Un ralentissement du réseau de la salle bloque la fusion de tout le
monde pendant sept minutes, et le message ne parle pas de réseau.
Une seule étape fait trois choses. ci.yml:275, « Audit et inventaire du
tableau de bord », enchaîne npm ci, npm audit et npm sbom. Le journal
n'impute rien : personne ne peut dire qui coûte quoi. C'est ce qui a fait
attribuer le problème à npm i.
Le cache npm rate dès que le verrou bouge. Il fonctionne quand la clé
tombe juste — ce sont les passages à 26 s. Il rate sur les demandes qui
touchent package-lock.json, c'est-à-dire celles du tableau de bord : #139 à
256 s puis 65 s au passage suivant, #140 en échec à 435 s puis 89 s.
Le job installe openssl par apt à chaque passage (ci.yml:263) pour un
openssl x509 -checkend que le job Python de la même exécution fait déjà. Il
n'a besoin que du fichier PEM pour NODE_EXTRA_CA_CERTS, pas du binaire.

Hors périmètre, à traiter avec le #141 : les quatre jobs se sérialisent
(exéc. #255, node démarre à 08:38:12, soit à la fin de Python), ce qui relève de
la capacity de l'exécuteur.

Critères d'acceptation

Aucun appel réseau de npm ne dépasse 60 s par tentative : les bornes vivent dans un fichier versionné, pas en option sur une ligne de commande.
Le job expose trois étapes distinctes — installation, audit, inventaire — chacune avec son temps propre dans le journal.
Sur un second passage d'une branche dont package-lock.json n'a pas bougé, l'installation est sautée et le journal le dit.
Aucun apt-get ne subsiste dans le job « Tableau de bord ».
npm audit reste bloquant sur une CVE de gravité haute : une dépendance vulnérable introduite fait toujours échouer la chaîne (ENF-11).
Le job est vert sur develop, et sa durée médiane sur dix exécutions consécutives est sous 90 s.

Comment on le vérifie

tests/ci/test-chaine-tableau-de-bord.sh, sur le modèle des quatre contrôles
statiques existants, joué par le job « Contrôles statiques du dépôt » :

tests/ci/test-chaine-tableau-de-bord.sh

Il vérifie statiquement les bornes npm, l'absence d'apt-get dans le job, une
clé de cache exacte sur package-lock.json sans restore-keys, et que
npm audit --audit-level=high figure toujours.

La durée se relève sur la forge, par nom de job, sur run_started_at et
updated_at :

curl -s -u <compte> \
  'http://localhost:3000/api/v1/repos/g2/enervision/actions/tasks?limit=50'

Joindre au ticket le tableau avant/après. Preuve du garde-fou :
npm audit --audit-level=high sur un package.json portant une dépendance
vulnérable connue doit sortir non nul.

Manuel d'exploitation à mettre à jour

docs/runbooks/ci.md. Son tableau décrit encore les six tâches d'avant le
#133 (qualite, tests-unitaires, dependances-python,
dependances-dashboard, images, secrets) alors que le workflow n'en a plus
que quatre. À réaligner, et à compléter par la conduite à tenir quand l'audit
npm échoue pour cause de réseau et non de CVE.

Risque et retour arrière

Un fetch-timeout trop court déplacerait la panne au lieu de la supprimer :
l'audit rougirait sur un simple ralentissement. 60 s avec deux réessais laisse
trois minutes de marge, à ajuster si la chaîne rougit pour cette raison.
Le cache de node_modules est le point sensible : un arbre partiellement
restauré est pire que pas de cache. D'où la clé exacte sans repli, et npm ci
rejoué dès qu'elle ne tombe pas juste.
Retour arrière : tout tient dans ci.yml, un .npmrc et un script de test.
Un git revert remet la chaîne dans son état actuel — lente et instable, mais
connue.
.forgejo/ et tests/ci/ sont à @lenaic dans CODEOWNERS, et sa demande
#145 touche la configuration de l'exécuteur. À séquencer après elle pour
éviter un conflit sur le même périmètre.

**Exigence couverte** : ENF-11 — chaîne d'approvisionnement **Épreuve servie** : EC03 · CI/CD et qualité ## Ce qu'on veut obtenir Suite du #133, qui a réuni les jobs et posé les caches. Le job Python en a profité : 124–129 s, stable, aucun échec. Le job « Tableau de bord » non. Mesuré sur les treize dernières exécutions de `ci.yml` (API `actions/tasks`) : | Job | Durées | |---|---| | Python — qualité, tests, dépendances | 124–129 s, 0 échec sur 13 | | **Tableau de bord** | 26 · 65 · 89 · 238 · 256 · 317 · 322 s, et **5 échecs sur 13, tous à 433–435 s** | | Contrôles statiques, secrets | 3–5 s | | **Total `ci.yml`** | 158 s → 688 s, médiane ≈ 6 min | `develop` est actuellement **rouge** sur ce job (exécution #240, échec à 433 s). Chronométré en local sur `services/dashboard` (244 paquets, 120 Mo) : ``` npm ci (cache npm vide) ........ 5,9 s npm ci (cache npm chaud) ....... 0,8 s vitest run (42 tests) ........... 1,9 s vite build ...................... 0,6 s npm audit --audit-level=high .... > 4 min, tué idem --fetch-timeout=30000 --fetch-retries=1 .... 12,5 s ``` Le coût n'est donc pas dans `npm ci`, contrairement à ce que le journal laisse croire. Quatre causes, distinctes : 1. **`npm audit` n'est pas borné.** `fetch-timeout` vaut 300 000 ms par défaut, `fetch-retries` 2, et aucun `.npmrc` n'est versionné. Les échecs se massent à 433–435 s : la signature d'un délai avec réessais, pas d'un travail à durée variable. Un ralentissement du réseau de la salle bloque la fusion de tout le monde pendant sept minutes, et le message ne parle pas de réseau. 2. **Une seule étape fait trois choses.** `ci.yml:275`, « Audit et inventaire du tableau de bord », enchaîne `npm ci`, `npm audit` et `npm sbom`. Le journal n'impute rien : personne ne peut dire qui coûte quoi. C'est ce qui a fait attribuer le problème à `npm i`. 3. **Le cache npm rate dès que le verrou bouge.** Il fonctionne quand la clé tombe juste — ce sont les passages à 26 s. Il rate sur les demandes qui touchent `package-lock.json`, c'est-à-dire celles du tableau de bord : #139 à 256 s puis 65 s au passage suivant, #140 en échec à 435 s puis 89 s. 4. **Le job installe openssl par apt à chaque passage** (`ci.yml:263`) pour un `openssl x509 -checkend` que le job Python de la même exécution fait déjà. Il n'a besoin que du fichier PEM pour `NODE_EXTRA_CA_CERTS`, pas du binaire. Hors périmètre, à traiter avec le #141 : les quatre jobs se sérialisent (exéc. #255, node démarre à 08:38:12, soit à la fin de Python), ce qui relève de la `capacity` de l'exécuteur. ## Critères d'acceptation - [x] Aucun appel réseau de npm ne dépasse 60 s par tentative : les bornes vivent dans un fichier versionné, pas en option sur une ligne de commande. - [x] Le job expose trois étapes distinctes — installation, audit, inventaire — chacune avec son temps propre dans le journal. - [x] Sur un second passage d'une branche dont `package-lock.json` n'a pas bougé, l'installation est sautée et le journal le dit. - [x] Aucun `apt-get` ne subsiste dans le job « Tableau de bord ». - [x] `npm audit` reste bloquant sur une CVE de gravité haute : une dépendance vulnérable introduite fait toujours échouer la chaîne (ENF-11). - [x] Le job est vert sur `develop`, et sa durée médiane sur dix exécutions consécutives est sous 90 s. ## Comment on le vérifie `tests/ci/test-chaine-tableau-de-bord.sh`, sur le modèle des quatre contrôles statiques existants, joué par le job « Contrôles statiques du dépôt » : ```bash tests/ci/test-chaine-tableau-de-bord.sh ``` Il vérifie statiquement les bornes npm, l'absence d'`apt-get` dans le job, une clé de cache exacte sur `package-lock.json` **sans** `restore-keys`, et que `npm audit --audit-level=high` figure toujours. La durée se relève sur la forge, par nom de job, sur `run_started_at` et `updated_at` : ```bash curl -s -u <compte> \ 'http://localhost:3000/api/v1/repos/g2/enervision/actions/tasks?limit=50' ``` Joindre au ticket le tableau avant/après. Preuve du garde-fou : `npm audit --audit-level=high` sur un `package.json` portant une dépendance vulnérable connue doit sortir non nul. ## Manuel d'exploitation à mettre à jour `docs/runbooks/ci.md`. Son tableau décrit encore les **six** tâches d'avant le #133 (`qualite`, `tests-unitaires`, `dependances-python`, `dependances-dashboard`, `images`, `secrets`) alors que le workflow n'en a plus que quatre. À réaligner, et à compléter par la conduite à tenir quand l'audit npm échoue pour cause de réseau et non de CVE. ## Risque et retour arrière - Un `fetch-timeout` trop court déplacerait la panne au lieu de la supprimer : l'audit rougirait sur un simple ralentissement. 60 s avec deux réessais laisse trois minutes de marge, à ajuster si la chaîne rougit pour cette raison. - Le cache de `node_modules` est le point sensible : un arbre partiellement restauré est pire que pas de cache. D'où la clé exacte sans repli, et `npm ci` rejoué dès qu'elle ne tombe pas juste. - Retour arrière : tout tient dans `ci.yml`, un `.npmrc` et un script de test. Un `git revert` remet la chaîne dans son état actuel — lente et instable, mais connue. - `.forgejo/` et `tests/ci/` sont à **@lenaic** dans CODEOWNERS, et sa demande #145 touche la configuration de l'exécuteur. À séquencer après elle pour éviter un conflit sur le même périmètre.

olivier added the

labels

2026-09-04 09:07:53 +00:00

lenaic self-assigned this

2026-09-04 09:27:28 +00:00

olivier referenced this issue

2026-09-04 09:31:19 +00:00

etl : agrégation et matérialisation de la zone or, export et lignage (#35) #124

lenaic referenced this issue

2026-09-04 09:36:53 +00:00

[148] Le job du tableau de bord : borné, découpé, et toujours bloquant #149

lenaic referenced this issue from a commit

2026-09-04 09:36:54 +00:00

outillage: borner, découper et garder bloquant le job du tableau de bord

olivier referenced this issue from a commit

2026-09-04 09:40:34 +00:00

outillage: la chaîne borne npm audit et cesse de réinstaller le tableau de bord (#148)

olivier referenced this issue

2026-09-04 09:42:00 +00:00

outillage : la chaîne borne npm audit et cesse de réinstaller le tableau de bord (#148) #151

olivier commented

2026-09-04 09:42:27 +00:00

Author

Member

Demande de fusion : #151.

Les quatre premiers critères sont couverts et vérifiés en local. Deux points restent ouverts :

Le sixième critère (« vert sur develop, durée médiane sous 90 s sur dix exécutions consécutives ») ne peut se mesurer qu'après passage sur develop. À relever avec l'API actions/tasks une fois fusionné.
Un arbitrage à trancher en relecture : j'ai gardé bloquant le cas « service d'avis npm injoignable », par cohérence avec le --strict de pip-audit et avec ENF-11. Conséquence assumée : un point d'accès npm en panne bloque encore les fusions, mais en 2 min au lieu de 7 et avec un message qui nomme la cause. Le détail est dans la demande.

Demande de fusion : #151. Les quatre premiers critères sont couverts et vérifiés en local. Deux points restent ouverts : - **Le sixième critère** (« vert sur `develop`, durée médiane sous 90 s sur dix exécutions consécutives ») ne peut se mesurer qu'après passage sur `develop`. À relever avec l'API `actions/tasks` une fois fusionné. - **Un arbitrage à trancher en relecture** : j'ai gardé bloquant le cas « service d'avis npm injoignable », par cohérence avec le `--strict` de pip-audit et avec ENF-11. Conséquence assumée : un point d'accès npm en panne bloque encore les fusions, mais en 2 min au lieu de 7 et avec un message qui nomme la cause. Le détail est dans la demande.

olivier referenced this issue

2026-09-04 09:48:59 +00:00

outillage : la chaîne borne npm audit et cesse de réinstaller le tableau de bord (#148) #151

olivier commented

2026-09-04 09:49:00 +00:00

Author

Member

Mon commentaire ci-dessus est caduc : la #151 est fermée, c'est la #149 de @lenaic qui traite ce ticket. Deux éléments repris en commentaire de la #151, dont une mesure qui concerne la #149 — les bornes ramènent le job de 435 s à 133 s, mais il échoue toujours quand le point d'accès npm est injoignable.

lenaic commented

2026-09-04 13:40:54 +00:00

Owner

Fusionné par la #149. Les six critères sont prouvés, y compris les deux qui
ne se mesuraient qu'après fusion.

Le relevé avant et après, promis en demande de fusion

Dix exécutions du job, relevées dans les journaux de tâches :

tâche 1318   11:53   434 s   ROUGE    avant le correctif
tâche 1310           23 s    vert
tâche 1314           23 s    vert
tâche 1330           22 s    vert
tâche 1348           18 s    vert     npm ci sauté
tâche 1357           20 s    vert     npm ci sauté
tâche 1361           19 s    vert     npm ci sauté
tâche 1366           18 s    vert     npm ci sauté
tâche 1370           21 s    vert     npm ci sauté
tâche 1374           20 s    vert     npm ci sauté

Médiane à 20 s, pour un palier fixé à 90 s. Contre 433 à 435 s sur les cinq
échecs d'avant, et une médiane de la chaîne entière à six minutes.

La tâche 1318 a démarré à 11 h 53, six minutes avant la fusion : elle ne porte pas
le correctif, et elle en montre exactement la signature.

Critère 3, l'installation sautée

Prouvé par le journal, tâche 1370 :

Arbre restauré du cache pour ce package-lock.json, npm ci sauté.
audit terminé en 1 s, aucune vulnérabilité high ou critical

L'audit prend une seconde. C'est la même commande qui immobilisait
l'exécuteur sept minutes ce matin.

Critères 1, 2 et 4, vérifiés sur `develop`

services/dashboard/.npmrc porte fetch-timeout=60000 et fetch-retries=2.
Le job expose trois étapes séparées, installation, inventaire, audit. Et zéro
apt-get y subsiste.

Critère 5, le garde-fou

Le verdict vit dans .forgejo/scripts/verdict-audit-npm.js et
tests/ci/test-verdict-audit-npm.sh l'exécute contre sept rapports figés : une
CVE haute et une critique bloquent, une moderée seule ne bloque pas, un registre
injoignable avertit, un rapport tronqué échoue plutôt que de passer pour une
panne.

Sortir cette logique du YAML était nécessaire : tant qu'elle y vivait, un banc ne
pouvait que chercher des sous-chaînes, et Olivier a démontré qu'un
process.exit(0) gardant v.high en affichage laissait le banc vert pendant que
les CVE cessaient de bloquer.

Le changement de politique

Une panne du registre npm avertit désormais au lieu de bloquer, une CVE bloquant
toujours. Tranché le 4 septembre, écrit dans docs/runbooks/ci.md avec ce que ça
coûte : une dépendance vulnérable introduite pendant une panne passe, et n'est
rattrapée qu'au passage suivant.

Reste ouvert, hors périmètre : la sérialisation des jobs faute d'un second
exécuteur, qui relève du #141.

Fusionné par la #149. **Les six critères sont prouvés**, y compris les deux qui ne se mesuraient qu'après fusion. ### Le relevé avant et après, promis en demande de fusion Dix exécutions du job, relevées dans les journaux de tâches : ``` tâche 1318 11:53 434 s ROUGE avant le correctif tâche 1310 23 s vert tâche 1314 23 s vert tâche 1330 22 s vert tâche 1348 18 s vert npm ci sauté tâche 1357 20 s vert npm ci sauté tâche 1361 19 s vert npm ci sauté tâche 1366 18 s vert npm ci sauté tâche 1370 21 s vert npm ci sauté tâche 1374 20 s vert npm ci sauté ``` **Médiane à 20 s**, pour un palier fixé à 90 s. Contre 433 à 435 s sur les cinq échecs d'avant, et une médiane de la chaîne entière à six minutes. La tâche 1318 a démarré à 11 h 53, six minutes avant la fusion : elle ne porte pas le correctif, et elle en montre exactement la signature. ### Critère 3, l'installation sautée Prouvé par le journal, tâche 1370 : ``` Arbre restauré du cache pour ce package-lock.json, npm ci sauté. audit terminé en 1 s, aucune vulnérabilité high ou critical ``` **L'audit prend une seconde.** C'est la même commande qui immobilisait l'exécuteur sept minutes ce matin. ### Critères 1, 2 et 4, vérifiés sur `develop` `services/dashboard/.npmrc` porte `fetch-timeout=60000` et `fetch-retries=2`. Le job expose trois étapes séparées, installation, inventaire, audit. Et zéro `apt-get` y subsiste. ### Critère 5, le garde-fou Le verdict vit dans `.forgejo/scripts/verdict-audit-npm.js` et `tests/ci/test-verdict-audit-npm.sh` l'exécute contre sept rapports figés : une CVE haute et une critique bloquent, une moderée seule ne bloque pas, un registre injoignable avertit, un rapport tronqué échoue plutôt que de passer pour une panne. Sortir cette logique du YAML était nécessaire : tant qu'elle y vivait, un banc ne pouvait que chercher des sous-chaînes, et Olivier a démontré qu'un `process.exit(0)` gardant `v.high` en affichage laissait le banc vert pendant que les CVE cessaient de bloquer. ### Le changement de politique Une panne du registre npm avertit désormais au lieu de bloquer, une CVE bloquant toujours. Tranché le 4 septembre, écrit dans `docs/runbooks/ci.md` avec ce que ça coûte : une dépendance vulnérable introduite pendant une panne passe, et n'est rattrapée qu'au passage suivant. Reste ouvert, hors périmètre : la sérialisation des jobs faute d'un second exécuteur, qui relève du #141.

lenaic closed this issue

2026-09-04 13:40:54 +00:00

Rows
Columns

[infra] Chaîne d'intégration : le job du tableau de bord échoue un tiers du temps sur un délai réseau non borné #148

Ce qu'on veut obtenir

Critères d'acceptation

Comment on le vérifie

Manuel d'exploitation à mettre à jour

Risque et retour arrière

Le relevé avant et après, promis en demande de fusion

Critère 3, l'installation sautée

Critères 1, 2 et 4, vérifiés sur develop

Critère 5, le garde-fou

Le changement de politique

Critères 1, 2 et 4, vérifiés sur `develop`