CI du tableau : passer les bancs Python concernés, pas seulement Rust et Svelte #1638

Merged

hermes-fusion merged 1 commit from hermes/ci-bancs-concernes into main 2026-10-15 21:30:09 +02:00

Conversation 4 Commits 1 Files changed 1 +85

hermes-bot commented 2026-10-14 20:43:16 +02:00

Collaborator

• Copy link
• Copy Markdown

Mandat — un écart rouge doit bloquer la fusion, pas seulement le déploiement.

Mesure du 2026-10-14 (carte t_91758efd, ticket STUD-1185) : .forgejo/workflows/tableau.yml (exécutant pc-studio, étiquette pc-lourd, mode host) ne faisait tourner que les tests Rust (_tableau/rust) et le front Svelte (vitest + build). python3 _tableau/lancer-tests.py n'y passait pas. Conséquence mesurée : une PR qui posait un habillage local dans un onglet (shadow-lg dans Calendrier.svelte) sortait la CI verte ; la fusion automatique la prenait, et seul deploy-132.sh refusait ensuite, à l'installation sur le 132. Le refus arrivait donc après la fusion, pas avant.

Ce que fait cette PR — un troisième métier bancs, sur le même exécutant pc-lourd :

1. git fetch origin main, puis git diff --name-only origin/main...HEAD : ce que la branche change face à main ;
2. controle/bancs_concernes.py choisit les bancs concernés (règle existante : module partagé touché → TOUT, sinon les bancs que les fichiers touchés citent ou que les balayeurs visent) ;
3. _tableau/lancer-tests.py les lance. Un module partagé touché fait passer le jeu complet (--tout), sans juger le cliquet de couverture.

Mesuré au dépôt, _tableau/front/ touché retient 4 bancs : test_garde_couches.py, test_garde_doublons.py, test_garde_plafond.py, test_homogeneite.py. Ces 4 passent en 8,6 s sur arbre propre. Le jeu complet (cas TOUT) : 153 bancs verts en 1 min 33 s.

Preuve exigée, sortie brute — deux états de cette même PR, et le retour en arrière :

• (a) PR propre → CI verte ;
• (b) la même PR + shadow-lg dans _tableau/front/src/Calendrier.svelte → CI rouge, le journal nommant _tableau/test_homogeneite.py :
  ÉCHEC garde : les onglets réels tiennent dans leurs exceptions (habillage local : 39 occurrence(s) dans les onglets, 38 admise(s) par exception, 1 refus) — code 1 ;
• puis retour en arrière de l'écart → CI verte à nouveau.

Déclencheur (relu dans le on:, confirmé par les runs de la forge) : poussée sur toute branche sauf main, et tout événement de pull request. Une PR poussée produit deux exécutions, une push et une pull_request ; les deux emploient pc-lourd. Les jobs tournent séquentiellement sur cet exécutant unique (mesuré : run 107, Rust 16 s puis Front 13 s).

Durée — avant : 25 à 34 s par run (Rust + Svelte). Après : voir les runs de cette PR ; le métier bancs ajoute le checkout à historique complet, le diff et les bancs concernés.

Limites dites, pas contournées

• Les bancs de controle/ concernés sont dits dans le journal sans être exécutés par cette CI : elle est celle du tableau, et livrer.sh / porte-complete.sh (nuit sur main) les tiennent déjà.
• Le passage réel de homogeneite.py (build + Chrome sans tête) n'est pas fait ici : le métier bancs fait son checkout sans dist/, et pc-studio n'a pas de Chrome. Il reste à livrer.sh (étape 4 bis) après la build. Le banc joué en CI est celui qui refuse l'habillage local, moteur de pilote remplacé par un faux.
• Le cliquet de couverture n'est pas jugé en CI (--sans-couverture sur le cas TOUT) : il reste à la porte de la nuit et à livrer.sh.

Front : aucun champ d'API changé, aucun besoin côté Svelte.

Branche : hermes/ci-bancs-concernes, partie de origin/main (119f2c12). Carte t_91758efd.

**Mandat** — un écart rouge doit bloquer la fusion, pas seulement le déploiement. Mesure du 2026-10-14 (carte `t_91758efd`, ticket STUD-1185) : `.forgejo/workflows/tableau.yml` (exécutant `pc-studio`, étiquette `pc-lourd`, mode host) ne faisait tourner que les tests Rust (`_tableau/rust`) et le front Svelte (`vitest` + build). `python3 _tableau/lancer-tests.py` n'y passait pas. Conséquence mesurée : une PR qui posait un habillage local dans un onglet (`shadow-lg` dans `Calendrier.svelte`) sortait la CI **verte** ; la fusion automatique la prenait, et seul `deploy-132.sh` refusait ensuite, à l'installation sur le 132. Le refus arrivait donc **après** la fusion, pas avant. **Ce que fait cette PR** — un troisième métier `bancs`, sur le même exécutant `pc-lourd` : 1. `git fetch origin main`, puis `git diff --name-only origin/main...HEAD` : ce que la branche change face à `main` ; 2. `controle/bancs_concernes.py` choisit les bancs concernés (règle existante : module partagé touché → `TOUT`, sinon les bancs que les fichiers touchés citent ou que les balayeurs visent) ; 3. `_tableau/lancer-tests.py` les lance. Un module partagé touché fait passer le jeu complet (`--tout`), sans juger le cliquet de couverture. Mesuré au dépôt, `_tableau/front/` touché retient 4 bancs : `test_garde_couches.py`, `test_garde_doublons.py`, `test_garde_plafond.py`, `test_homogeneite.py`. Ces 4 passent en 8,6 s sur arbre propre. Le jeu complet (cas `TOUT`) : 153 bancs verts en 1 min 33 s. **Preuve exigée, sortie brute** — deux états de cette même PR, et le retour en arrière : - (a) PR propre → CI verte ; - (b) la même PR + `shadow-lg` dans `_tableau/front/src/Calendrier.svelte` → CI rouge, le journal nommant `_tableau/test_homogeneite.py` : `ÉCHEC garde : les onglets réels tiennent dans leurs exceptions (habillage local : 39 occurrence(s) dans les onglets, 38 admise(s) par exception, 1 refus)` — code 1 ; - puis retour en arrière de l'écart → CI verte à nouveau. **Déclencheur** (relu dans le `on:`, confirmé par les runs de la forge) : poussée sur toute branche sauf `main`, et tout événement de pull request. Une PR poussée produit **deux** exécutions, une `push` et une `pull_request` ; les deux emploient `pc-lourd`. Les jobs tournent **séquentiellement** sur cet exécutant unique (mesuré : run 107, Rust 16 s puis Front 13 s). **Durée** — avant : 25 à 34 s par run (Rust + Svelte). Après : voir les runs de cette PR ; le métier `bancs` ajoute le checkout à historique complet, le diff et les bancs concernés. **Limites dites, pas contournées** - Les bancs de `controle/` concernés sont **dits dans le journal sans être exécutés** par cette CI : elle est celle du tableau, et `livrer.sh` / `porte-complete.sh` (nuit sur `main`) les tiennent déjà. - Le passage réel de `homogeneite.py` (build + Chrome sans tête) n'est pas fait ici : le métier `bancs` fait son checkout sans `dist/`, et `pc-studio` n'a pas de Chrome. Il reste à `livrer.sh` (étape 4 bis) après la build. Le banc joué en CI est celui qui refuse l'habillage local, moteur de pilote remplacé par un faux. - Le cliquet de couverture n'est pas jugé en CI (`--sans-couverture` sur le cas `TOUT`) : il reste à la porte de la nuit et à `livrer.sh`. **Front** : aucun champ d'API changé, aucun besoin côté Svelte. Branche : `hermes/ci-bancs-concernes`, partie de `origin/main` (119f2c12). Carte `t_91758efd`.

hermes-bot added 1 commit 2026-10-14 20:43:16 +02:00

CI du tableau : passer les bancs Python concernés, pas seulement Rust et Svelte ... 8c8e2d3bdd

Le workflow de la forge ne faisait tourner que `_tableau/rust` (cargo) et le front
Svelte (vitest + build). `python3 _tableau/lancer-tests.py` n'y passait pas.
Mesuré le 2026-10-14 (carte t_91758efd, ticket STUD-1185) : une PR qui posait un
habillage local dans un onglet (`shadow-lg` dans `Calendrier.svelte`) sortait CI
verte ; la fusion automatique la prenait, et seul `deploy-132.sh` refusait ensuite,
à l'installation sur le 132. Le refus arrivait donc après la fusion, pas avant.

Remède : un troisième métier `bancs`, sur le même exécutant pc-lourd, qui prend le
diff face à `origin/main`, demande à `controle/bancs_concernes.py` les bancs
concernés, et les lance par `_tableau/lancer-tests.py`. Un module partagé touché
fait passer le jeu complet. Les bancs de `controle/` concernés sont dits sans être
exécutés ici : cette CI est celle du tableau, la porte complète les tient déjà.

hermes-bot added 1 commit 2026-10-14 20:45:59 +02:00

ESSAI : habillage local volontaire (shadow-lg) pour mesurer que la CI refuse ... 76e7e620b5

Ce commit ne doit pas rester : il éprouve que le métier  de la CI
fait sortir un écart rouge AVANT la fusion, au lieu de laisser la fusion
automatique passer et le déploiement refuser.

hermes-bot force-pushed hermes/ci-bancs-concernes from 76e7e620b5 to 8c8e2d3bdd 2026-10-14 20:48:43 +02:00 Compare

hermes-bot commented 2026-10-14 20:49:47 +02:00

Author

Collaborator

• Copy link
• Copy Markdown

Preuve mesurée — carte t_91758efd (STUD-1185). Branche hermes/ci-bancs-concernes, tête 8c8e2d3b, partie de origin/main (119f2c12).

Déclencheur et étiquette (ce que je constate). Le on: déclenche une poussée sur toute branche sauf main, et tout événement de pull request. Les deux exécutions tournent bien sur pc-lourd : mesuré, le même commit produit un run push ET un run pull_request, les trois métiers verts dans les deux — run 108 (push) et run 113 (pull_request) pour 8c8e2d3b, puis run 120 (push) après le retour en arrière. L'étiquette pc-lourd se retrouve donc bien sur une pull request ; l'exécutant pc-studio a une capacité de 1 (capacity: 1 dans ~/.config/forgejo-runner/studio/config.yml), donc les métiers tournent l'un après l'autre, pas en parallèle.

Durées.

	Rust	Front	Bancs	total du run
avant (Rust + Svelte)	14 s	11 à 15 s	—	25 à 34 s
après, PR qui ne touche rien du tableau	14 s	11 à 14 s	4 s	30 à 32 s
après, PR qui touche _tableau/front/	14 à 18 s	13 s	13 s	41 à 45 s

Preuve (a) — PR propre, CI verte. Le métier bancs ne retient rien et le dit (run push 108, job 11783) :

--- fichiers touchés (git diff origin/main...HEAD) ---
.forgejo/workflows/tableau.yml
--- bancs concernés (controle/bancs_concernes.py) ---
Aucun banc du tableau concerné par ces fichiers : rien à passer.
🏁  Job succeeded

Preuve (b) — la même PR + shadow-lg dans _tableau/front/src/Calendrier.svelte, CI ROUGE. Run push 116, job 11801 : le métier bancs sort en échec, Rust et Front restent verts (l'écart passait donc bien avant, sous la CI verte) :

--- fichiers touchés (git diff origin/main...HEAD) ---
_tableau/front/src/Calendrier.svelte
--- bancs concernés (controle/bancs_concernes.py) ---
_tableau/test_garde_couches.py
_tableau/test_garde_doublons.py
_tableau/test_garde_plafond.py
_tableau/test_homogeneite.py
--- _tableau/lancer-tests.py ---
ok    _tableau/test_garde_couches.py
ok    _tableau/test_garde_doublons.py
ok    _tableau/test_garde_plafond.py
ROUGE _tableau/test_homogeneite.py (code 1)
      | ÉCHEC garde : les onglets réels tiennent dans leurs exceptions (habillage local : 39 occurrence(s) dans les onglets, 38 admise(s) par exception, 1 refus)
1 banc(s) en échec : _tableau/test_homogeneite.py
⚙️ [runner]: RUN exit status 1
🏁  Job failed
Job 'Bancs Python concernés (_tableau)' failed

Le même écart a été vu deux fois — run push 116 (job 11801) et run pull_request 117 (job 10375). Le commit d'essai (76e7e620) a été retiré de la branche après la mesure : la tête de la PR est le correctif seul, 8c8e2d3b, et sa CI est verte (runs 108, 113 et 120).

Limites, dites et non contournées.

• Les bancs de controle/ que bancs_concernes.py retient sont nommés dans le journal sans être exécutés : cette CI est celle du tableau (_tableau/, _infra/ via lancer-tests.py), la porte complète de livrer.sh et la passe de nuit (controle/porte-complete.sh) les tiennent déjà. L'étendre serait une autre carte.
• Cas TOUT (module partagé touché : charte.py, etat.py, livrer.sh, lancer-tests.py…) : le métier passe le jeu complet des bancs du tableau, _tableau/lancer-tests.py --tout --sans-couverture. Mesuré au dépôt le 2026-10-14 : 153 bancs verts en 1 min 33 s. Le cliquet de couverture n'y est pas jugé (--sans-couverture) : il reste à la porte de la nuit sur main et à livrer.sh, pour ne pas écrire _tableau/couverture-objectif.json dans un checkout d'exécutant que personne ne relit.
• Le passage réel de homogeneite.py (build + Chrome sans tête, comparaison de captures) n'est pas fait ici : le checkout du métier bancs n'a pas de dist/ et pc-studio n'a pas de Chrome à nous. Ce passage reste à livrer.sh (étape 4 bis) après la build. Le banc joué en CI est celui qui refuse l'habillage local, moteur de pilote remplacé par un faux — c'est lui qui attrape le shadow-lg.

Front : aucun champ d'API changé, aucun besoin côté Svelte.

**Preuve mesurée** — carte `t_91758efd` (STUD-1185). Branche `hermes/ci-bancs-concernes`, tête `8c8e2d3b`, partie de `origin/main` (119f2c12). **Déclencheur et étiquette (ce que je constate).** Le `on:` déclenche une poussée sur toute branche sauf `main`, et tout événement de pull request. Les deux exécutions tournent bien sur `pc-lourd` : mesuré, le même commit produit un run `push` ET un run `pull_request`, les trois métiers verts dans les deux — run 108 (`push`) et run 113 (`pull_request`) pour `8c8e2d3b`, puis run 120 (`push`) après le retour en arrière. L'étiquette `pc-lourd` se retrouve donc bien sur une pull request ; l'exécutant `pc-studio` a une capacité de 1 (`capacity: 1` dans `~/.config/forgejo-runner/studio/config.yml`), donc les métiers tournent l'un après l'autre, pas en parallèle. **Durées.** | | Rust | Front | Bancs | total du run | |---|---|---|---|---| | avant (Rust + Svelte) | 14 s | 11 à 15 s | — | 25 à 34 s | | après, PR qui ne touche rien du tableau | 14 s | 11 à 14 s | 4 s | 30 à 32 s | | après, PR qui touche `_tableau/front/` | 14 à 18 s | 13 s | 13 s | 41 à 45 s | **Preuve (a) — PR propre, CI verte.** Le métier `bancs` ne retient rien et le dit (run `push` 108, job 11783) : ``` --- fichiers touchés (git diff origin/main...HEAD) --- .forgejo/workflows/tableau.yml --- bancs concernés (controle/bancs_concernes.py) --- Aucun banc du tableau concerné par ces fichiers : rien à passer. 🏁 Job succeeded ``` **Preuve (b) — la même PR + `shadow-lg` dans `_tableau/front/src/Calendrier.svelte`, CI ROUGE.** Run `push` 116, job 11801 : le métier `bancs` sort en échec, Rust et Front restent verts (l'écart passait donc bien avant, sous la CI verte) : ``` --- fichiers touchés (git diff origin/main...HEAD) --- _tableau/front/src/Calendrier.svelte --- bancs concernés (controle/bancs_concernes.py) --- _tableau/test_garde_couches.py _tableau/test_garde_doublons.py _tableau/test_garde_plafond.py _tableau/test_homogeneite.py --- _tableau/lancer-tests.py --- ok _tableau/test_garde_couches.py ok _tableau/test_garde_doublons.py ok _tableau/test_garde_plafond.py ROUGE _tableau/test_homogeneite.py (code 1) | ÉCHEC garde : les onglets réels tiennent dans leurs exceptions (habillage local : 39 occurrence(s) dans les onglets, 38 admise(s) par exception, 1 refus) 1 banc(s) en échec : _tableau/test_homogeneite.py ⚙️ [runner]: RUN exit status 1 🏁 Job failed Job 'Bancs Python concernés (_tableau)' failed ``` Le même écart a été vu deux fois — run `push` 116 (job 11801) et run `pull_request` 117 (job 10375). Le commit d'essai (76e7e620) a été **retiré** de la branche après la mesure : la tête de la PR est le correctif seul, `8c8e2d3b`, et sa CI est verte (runs 108, 113 et 120). **Limites, dites et non contournées.** - Les bancs de `controle/` que `bancs_concernes.py` retient sont **nommés dans le journal sans être exécutés** : cette CI est celle du tableau (`_tableau/`, `_infra/` via `lancer-tests.py`), la porte complète de `livrer.sh` et la passe de nuit (`controle/porte-complete.sh`) les tiennent déjà. L'étendre serait une autre carte. - Cas `TOUT` (module partagé touché : `charte.py`, `etat.py`, `livrer.sh`, `lancer-tests.py`…) : le métier passe le jeu complet des bancs du tableau, `_tableau/lancer-tests.py --tout --sans-couverture`. Mesuré au dépôt le 2026-10-14 : **153 bancs verts en 1 min 33 s**. Le cliquet de couverture n'y est pas jugé (`--sans-couverture`) : il reste à la porte de la nuit sur `main` et à `livrer.sh`, pour ne pas écrire `_tableau/couverture-objectif.json` dans un checkout d'exécutant que personne ne relit. - Le passage **réel** de `homogeneite.py` (build + Chrome sans tête, comparaison de captures) n'est pas fait ici : le checkout du métier `bancs` n'a pas de `dist/` et `pc-studio` n'a pas de Chrome à nous. Ce passage reste à `livrer.sh` (étape 4 bis) après la build. Le banc joué en CI est celui qui refuse l'habillage local, moteur de pilote remplacé par un faux — c'est lui qui attrape le `shadow-lg`. **Front** : aucun champ d'API changé, aucun besoin côté Svelte.

hermes-bot commented 2026-10-14 21:34:41 +02:00

Author

Collaborator

• Copy link
• Copy Markdown

Relecture t_d0af0831 — relu, conforme.

Dépôt ~/atelier-hermes/studio (PC de l'opérateur), worktree de relecture ~/atelier-hermes/wt/t_d0af0831 sur la tête 8c8e2d3b, origin/main à jour = b4712395, le 2026-10-14 à 21 h 35.

1. Le diff — une seule pièce

git -C ~/atelier-hermes/wt/t_d0af0831 diff --stat origin/main...HEAD
 .forgejo/workflows/tableau.yml | 77 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 75 insertions(+), 2 deletions(-)

Les deux lignes retirées sont l'ancien name: et le commentaire « cargo et npm sont installés directement sur le PC » ; le bloc on: est inchangé (lignes de contexte du diff), et aucun autre fichier n'apparaît. Aucun emoji, aucun secret, aucun binaire dans le diff (grep des deux motifs : rien).

2. Ce que la CI exécute sur cette tête (8c8e2d3b), lu par l'API de la forge

run 108 (push, index 120)          : jobs 11781 Rust, 11782 Front, 11783 Bancs — success
run 113 (pull_request, #1638)      : jobs 11792 Rust, 11793 Front, 11794 Bancs — success
run 120 (push)                     : jobs 11809 Rust, 11810 Front, 11811 Bancs — success

Durée du métier bancs quand il n'y a rien à passer : 3,6 s (journal du job 11794). Limite dite : sur cette tête, git diff --name-only origin/main...HEAD ne donne que .forgejo/workflows/tableau.yml, donc le journal du job 11794 dit « Aucun banc du tableau concerné par ces fichiers : rien à passer. » — le vert de cette tête prouve que le métier existe et passe, pas qu'un banc tourne. La preuve que le banc tourne est le point 3.

3. Le rouge, rejoué

Sur la même branche poussée avec shadow-lg dans _tableau/front/src/Calendrier.svelte (76e7e620), runs 116 (push) et 117 (pull_request), job 11801 / 11799 « Bancs Python concernés » = failure ; extrait du journal :

--- fichiers touchés (git diff origin/main...HEAD) ---
_tableau/front/src/Calendrier.svelte
--- bancs concernés (controle/bancs_concernes.py) ---
_tableau/test_garde_couches.py
_tableau/test_garde_doublons.py
_tableau/test_garde_plafond.py
_tableau/test_homogeneite.py
ROUGE _tableau/test_homogeneite.py (code 1)
  | ÉCHEC garde : les onglets réels tiennent dans leurs exceptions (habillage local : 39 occurrence(s) dans les onglets, 38 admise(s) par exception, 1 refus)
1 banc(s) en échec : _tableau/test_homogeneite.py
⚙️ [runner]: RUN exit status 1

Rejoué chez moi sur origin/main (b4712395) + ce workflow seul : printf '_tableau/front/src/Calendrier.svelte\n' | python3 controle/bancs_concernes.py → les 4 mêmes bancs, python3 _tableau/lancer-tests.py sur ces 4 → 4 banc(s) verts en 10,5 s. Puis shadow-lg posé à la main dans Calendrier.svelte → 1 banc(s) en échec : _tableau/test_homogeneite.py, le même message, code 1. Retour en arrière fait (git status propre côté arbre, seule la copie du workflow modifiée dans mon arbre d'essai).

4. Le cas du module partagé — mesuré, et ce n'est pas le jeu complet

printf '_tableau/socle.py\n'     | python3 controle/bancs_concernes.py | wc -l   → 135, aucune ligne TOUT
printf '_tableau/tb_chaines.py\n' | python3 controle/bancs_concernes.py | wc -l   → 141, aucune ligne TOUT

Ni _tableau/socle.py ni _tableau/tb_chaines.py ne sont dans PARTAGES (charte.py, jetons.py, motion_montage.py, provenance.py, etat.py, livrer.sh, controle/bancs_concernes.py, controle/porte-complete.sh, _tableau/lancer-tests.py, _tableau/couverture-objectif.json, requirements.txt, pyproject.toml, dependances-systeme.txt). Ces deux fichiers sont donc retenus par la règle de citation et d'import (plus les trois balayeurs _tableau/*) — ce n'est pas la lecture étroite du nom du fichier — mais le jeu complet n'est pas lancé : sur 240 bancs, 105 restent dehors (8 _infra, 66 controle, 31 _tableau dont test_homogeneite.py, test_charte_svelte.py, test_captures_charte.py).

C'est le comportement de controle/bancs_concernes.py sur main, pas un effet de cette PR, et le filet du studio reste la passe de nuit (controle/porte-complete.sh, jeu complet sur main). Suite possible, 2 lignes + une assertion dans controle/test_bancs_concernes.py : ajouter _tableau/socle.py et _tableau/tb_chaines.py à PARTAGES. Je ne la fais pas ici et je ne la commande pas : c'est au chef de décider.

5. La garde du métier

controle/bancs_concernes.py n'est pas touché par cette PR (git diff origin/main...HEAD -- controle/bancs_concernes.py : 0 ligne), donc le motif NOM ([A-Za-z0-9_.\-]+\.(?:py|sh|json|html|js|css|txt|csv)\b) est celui de main, non élargi. Le workflow cite bien controle/bancs_concernes.py (étape « Bancs concernés par les fichiers touchés ») et _tableau/lancer-tests.py (même métier bancs, runs-on: pc-lourd).

Contrôle plus fort : le banc _tableau/test_garde_ci.py de la carte sœur t_806e83dc (branche hermes/banc-garde-ci-tableau, pas encore de PR), exécuté sur ce workflow, rend

ecarts_workflow(<workflow de #1638>) -> []
metiers: [('rust','pc-lourd'), ('front','pc-lourd'), ('bancs','pc-lourd')]
appels : {'rust': (False, False), 'front': (False, False), 'bancs': (True, True)}

donc retirer ce métier, ou l'un de ses deux appels, fera rougir la garde de la carte sœur — la porte demandée tient.

6. Compatibilité avec le chantier tmpfs (t_5d5edc3d) — compatible tel quel

Le métier appelle python3 _tableau/lancer-tests.py (trois formes : liste de bancs, --tout --sans-couverture, ou rien) sans aucune option d'environnement et sans écrire dans TMPDIR ; la correction prévue pose TMPDIR dans le lanceur et laisse son CLI (et la couverture, et le cliquet) inchangé : aucune des trois formes n'est contredite. Le futur code de sortie 2 « mesure impossible : disque plein » ferait rougir ce métier — c'est le comportement voulu (un rouge visible plutôt qu'un faux ROUGE compté).

Ce que je n'ai pas pu mesurer là : la branche hermes/temp-des-bancs-hors-tmpfs n'a encore aucun commit (git log bede6a69..hermes/temp-des-bancs-hors-tmpfs : vide) et git grep TMPDIR origin/main sur _tableau, controle, livrer.sh, .forgejo ne rend rien — la correction n'est pas écrite, je n'ai vérifié que l'absence d'option côté workflow. État du disque à l'instant : df -h /tmp → tmpfs 16 G, 6,8 G utilisés (45 %), 27 598 entrées : la saturation de 99 % relevée à 21 h 20 n'est plus là. Un lancement lourd du métier bancs avant la correction peut encore remplir /tmp : ce serait un rouge visible, pas un échec avalé.

Ce que je n'ai pas mesuré : le cas TOUT en CI (aucun run ne l'a pris), la durée d'un jeu complet sur pc-lourd, le chemin pull_request venu d'une fourche, et la correction tmpfs (pas encore écrite).

Aucun fichier de _tableau/front n'est touché : rien à regarder dans le navigateur ; aucune fonction visible retirée, aucun onglet écrasé, aucune route ni champ d'API modifié.

**Relecture `t_d0af0831` — relu, conforme.** Dépôt `~/atelier-hermes/studio` (PC de l'opérateur), worktree de relecture `~/atelier-hermes/wt/t_d0af0831` sur la tête `8c8e2d3b`, `origin/main` à jour = `b4712395`, le 2026-10-14 à 21 h 35. **1. Le diff — une seule pièce** git -C ~/atelier-hermes/wt/t_d0af0831 diff --stat origin/main...HEAD .forgejo/workflows/tableau.yml | 77 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 75 insertions(+), 2 deletions(-) Les deux lignes retirées sont l'ancien `name:` et le commentaire « cargo et npm sont installés directement sur le PC » ; le bloc `on:` est inchangé (lignes de contexte du diff), et aucun autre fichier n'apparaît. Aucun emoji, aucun secret, aucun binaire dans le diff (`grep` des deux motifs : rien). **2. Ce que la CI exécute sur cette tête (8c8e2d3b), lu par l'API de la forge** run 108 (push, index 120) : jobs 11781 Rust, 11782 Front, 11783 Bancs — success run 113 (pull_request, #1638) : jobs 11792 Rust, 11793 Front, 11794 Bancs — success run 120 (push) : jobs 11809 Rust, 11810 Front, 11811 Bancs — success Durée du métier `bancs` quand il n'y a rien à passer : 3,6 s (journal du job 11794). Limite dite : sur cette tête, `git diff --name-only origin/main...HEAD` ne donne que `.forgejo/workflows/tableau.yml`, donc le journal du job 11794 dit « Aucun banc du tableau concerné par ces fichiers : rien à passer. » — le vert de cette tête prouve que le métier existe et passe, **pas** qu'un banc tourne. La preuve que le banc tourne est le point 3. **3. Le rouge, rejoué** Sur la même branche poussée avec `shadow-lg` dans `_tableau/front/src/Calendrier.svelte` (`76e7e620`), runs 116 (push) et 117 (pull_request), job 11801 / 11799 « Bancs Python concernés » = **failure** ; extrait du journal : --- fichiers touchés (git diff origin/main...HEAD) --- _tableau/front/src/Calendrier.svelte --- bancs concernés (controle/bancs_concernes.py) --- _tableau/test_garde_couches.py _tableau/test_garde_doublons.py _tableau/test_garde_plafond.py _tableau/test_homogeneite.py ROUGE _tableau/test_homogeneite.py (code 1) | ÉCHEC garde : les onglets réels tiennent dans leurs exceptions (habillage local : 39 occurrence(s) dans les onglets, 38 admise(s) par exception, 1 refus) 1 banc(s) en échec : _tableau/test_homogeneite.py ⚙️ [runner]: RUN exit status 1 Rejoué chez moi sur `origin/main` (`b4712395`) + ce workflow seul : `printf '_tableau/front/src/Calendrier.svelte\n' | python3 controle/bancs_concernes.py` → les 4 mêmes bancs, `python3 _tableau/lancer-tests.py` sur ces 4 → `4 banc(s) verts` en 10,5 s. Puis `shadow-lg` posé à la main dans `Calendrier.svelte` → `1 banc(s) en échec : _tableau/test_homogeneite.py`, le même message, code 1. Retour en arrière fait (`git status` propre côté arbre, seule la copie du workflow modifiée dans mon arbre d'essai). **4. Le cas du module partagé — mesuré, et ce n'est pas le jeu complet** printf '_tableau/socle.py\n' | python3 controle/bancs_concernes.py | wc -l → 135, aucune ligne TOUT printf '_tableau/tb_chaines.py\n' | python3 controle/bancs_concernes.py | wc -l → 141, aucune ligne TOUT Ni `_tableau/socle.py` ni `_tableau/tb_chaines.py` ne sont dans `PARTAGES` (`charte.py`, `jetons.py`, `motion_montage.py`, `provenance.py`, `etat.py`, `livrer.sh`, `controle/bancs_concernes.py`, `controle/porte-complete.sh`, `_tableau/lancer-tests.py`, `_tableau/couverture-objectif.json`, `requirements.txt`, `pyproject.toml`, `dependances-systeme.txt`). Ces deux fichiers sont donc retenus par la règle de citation et d'import (plus les trois balayeurs `_tableau/*`) — ce n'est pas la lecture étroite du nom du fichier — mais **le jeu complet n'est pas lancé** : sur 240 bancs, 105 restent dehors (8 `_infra`, 66 `controle`, 31 `_tableau` dont `test_homogeneite.py`, `test_charte_svelte.py`, `test_captures_charte.py`). C'est le comportement de `controle/bancs_concernes.py` **sur `main`**, pas un effet de cette PR, et le filet du studio reste la passe de nuit (`controle/porte-complete.sh`, jeu complet sur `main`). Suite possible, 2 lignes + une assertion dans `controle/test_bancs_concernes.py` : ajouter `_tableau/socle.py` et `_tableau/tb_chaines.py` à `PARTAGES`. Je ne la fais pas ici et je ne la commande pas : c'est au chef de décider. **5. La garde du métier** `controle/bancs_concernes.py` n'est pas touché par cette PR (`git diff origin/main...HEAD -- controle/bancs_concernes.py` : 0 ligne), donc le motif `NOM` (`[A-Za-z0-9_.\-]+\.(?:py|sh|json|html|js|css|txt|csv)\b`) est celui de `main`, non élargi. Le workflow cite bien `controle/bancs_concernes.py` (étape « Bancs concernés par les fichiers touchés ») et `_tableau/lancer-tests.py` (même métier `bancs`, `runs-on: pc-lourd`). Contrôle plus fort : le banc `_tableau/test_garde_ci.py` de la carte sœur `t_806e83dc` (branche `hermes/banc-garde-ci-tableau`, pas encore de PR), exécuté sur ce workflow, rend ecarts_workflow(<workflow de #1638>) -> [] metiers: [('rust','pc-lourd'), ('front','pc-lourd'), ('bancs','pc-lourd')] appels : {'rust': (False, False), 'front': (False, False), 'bancs': (True, True)} donc retirer ce métier, ou l'un de ses deux appels, fera rougir la garde de la carte sœur — la porte demandée tient. **6. Compatibilité avec le chantier `tmpfs` (`t_5d5edc3d`) — compatible tel quel** Le métier appelle `python3 _tableau/lancer-tests.py` (trois formes : liste de bancs, `--tout --sans-couverture`, ou rien) sans aucune option d'environnement et sans écrire dans `TMPDIR` ; la correction prévue pose `TMPDIR` **dans** le lanceur et laisse son CLI (et la couverture, et le cliquet) inchangé : aucune des trois formes n'est contredite. Le futur code de sortie 2 « mesure impossible : disque plein » ferait rougir ce métier — c'est le comportement voulu (un rouge visible plutôt qu'un faux ROUGE compté). Ce que je n'ai pas pu mesurer là : la branche `hermes/temp-des-bancs-hors-tmpfs` n'a encore **aucun commit** (`git log bede6a69..hermes/temp-des-bancs-hors-tmpfs` : vide) et `git grep TMPDIR origin/main` sur `_tableau`, `controle`, `livrer.sh`, `.forgejo` ne rend rien — la correction n'est pas écrite, je n'ai vérifié que l'absence d'option côté workflow. État du disque à l'instant : `df -h /tmp` → tmpfs 16 G, 6,8 G utilisés (45 %), 27 598 entrées : la saturation de 99 % relevée à 21 h 20 n'est plus là. Un lancement lourd du métier `bancs` avant la correction peut encore remplir `/tmp` : ce serait un rouge visible, pas un échec avalé. **Ce que je n'ai pas mesuré** : le cas `TOUT` en CI (aucun run ne l'a pris), la durée d'un jeu complet sur `pc-lourd`, le chemin `pull_request` venu d'une fourche, et la correction `tmpfs` (pas encore écrite). Aucun fichier de `_tableau/front` n'est touché : rien à regarder dans le navigateur ; aucune fonction visible retirée, aucun onglet écrasé, aucune route ni champ d'API modifié.

hermes-bot added the

relu

label 2026-10-14 21:34:46 +02:00

hermes-bot force-pushed hermes/ci-bancs-concernes from 8c8e2d3bdd to b956d71bb1 2026-10-14 23:11:20 +02:00 Compare

hermes-bot referenced this pull request 2026-10-15 00:09:09 +02:00

Les temp des bancs hors du tmpfs : le lanceur pose TMPDIR, élague, et refuse de compter un disque plein (t_5d5edc3d) #1653

hermes-fusion added the

conflit

label 2026-10-15 08:00:03 +02:00

hermes-fusion commented 2026-10-15 08:00:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot force-pushed hermes/ci-bancs-concernes from b956d71bb1 to 3aa06e4ade 2026-10-15 12:15:26 +02:00 Compare

hermes-fusion removed the

conflit

label 2026-10-15 12:20:03 +02:00

hermes-bot referenced this pull request from a commit 2026-10-15 16:31:19 +02:00

Garde de la CI du tableau : un banc refuse le workflow sans les bancs du tableau

hermes-bot referenced this pull request 2026-10-15 16:31:30 +02:00

Garde de la CI du tableau : un banc refuse le workflow sans les bancs du tableau #1738

hermes-bot referenced this pull request from a commit 2026-10-15 16:37:43 +02:00

Garde de la CI du tableau : un banc refuse le workflow sans les bancs du tableau

hermes-bot added 1 commit 2026-10-15 21:21:40 +02:00

CI du tableau : les bancs Python concernés par la branche alimentent le passage ... 1a9f1b9d3a

Cause : le choix des bancs (`controle/bancs_concernes.py`) n'était employé que pour les
bancs de `controle/` ; les bancs du tableau passaient tous par `--tout`, un jeu complet qui
ne dépend d'aucun choix. Le banc qui garde ce fichier, `_tableau/test_garde_ci.py`, le
nomme : « rien, dans `main`, ne relie `bancs_concernes.py` à `lancer-tests.py` ».

Remède : une étape de plus dans le métier « Rust (_tableau/rust) » — pas un troisième
métier, la fusion automatique n'attend que les deux noms. Elle prend le choix, passe les
bancs `_tableau/` et `_infra/` concernés par `_tableau/lancer-tests.py`, juge un rouge
contre `origin/main` (contrôle 4 de `livrer.sh`), et ne refait pas le jeu complet quand le
choix rend TOUT (le doublon écarté).

hermes-fusion merged commit a3043cb8d5 into main 2026-10-15 21:30:09 +02:00

hermes-fusion deleted branch hermes/ci-bancs-concernes 2026-10-15 21:30:09 +02:00

hermes-fusion commented 2026-10-15 21:30:09 +02:00

Collaborator

• Copy link
• Copy Markdown

Fusionnée automatiquement par fusion-auto (forge) : CI verte, sans conflit.

Fusionnée automatiquement par `fusion-auto` (forge) : CI verte, sans conflit.

hermes-fusion referenced this pull request from a commit 2026-10-15 21:30:11 +02:00

Merge pull request 'CI du tableau : passer les bancs Python concernés, pas seulement Rust et Svelte' (#1638) from hermes/ci-bancs-concernes into main

hermes-bot referenced this pull request from a commit 2026-10-16 18:07:34 +02:00

fix(tools): remove unnecessary crontab requirement from cronjob tool (#1638)

hermes-bot referenced this pull request from a commit 2026-10-17 04:24:51 +02:00

fix(docker): egress-off reuse probe uses a label filter, not the Docker-only {{.Label}} template (#99213)

hermes-bot referenced this pull request from a commit 2026-10-17 13:20:03 +02:00

fix(security): corrupt-token and docker_env warnings stop logging credential material (#102308)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

ci-rouge

La CI de la PR est rouge : pas de fusion automatique

  

conflit

La PR est en conflit avec main : à rebaser

  

operateur

Cas sensible : seul l operateur fusionne

  

relu

Relue et validée par le relecteur de l atelier Hermes : la fusion automatique peut la prendre

No labels

ci-rouge

conflit

operateur

relu

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

foXaCe/studio!1638

No description provided.