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

Merged

hermes-fusion merged 1 commit from hermes/banc-garde-ci-tableau into main 2026-10-15 16:55:03 +02:00

Conversation 1 Commits 1 Files changed 2 +380

hermes-bot commented 2026-10-15 16:31:30 +02:00

Collaborator

• Copy link
• Copy Markdown

Ce que fait cette PR

Un banc de garde : _tableau/test_garde_ci.py lit .forgejo/workflows/tableau.yml et sort 1 si
aucun métier tournant sur pc-lourd n'appelle à la fois controle/bancs_concernes.py (le choix
des bancs concernés) et _tableau/lancer-tests.py (leur passage).

Pourquoi : rien ne gardait cette chaîne. La retirer du workflow ne faisait rougir aucune porte —
la CI repassait Rust et Svelte comme avant, et le refus d'un onglet habillé ne revenait qu'au
deploy-132.sh, après fusion.

Mesures (2026-10-15, branche 81fca6af)

$ python3 _tableau/test_garde_ci.py ; echo rc=$?
OK  workflow sans métier bancs (rust + front seuls) : REFUSÉ
OK  métier bancs sans lancer-tests.py : REFUSÉ
OK  métier bancs sans bancs_concernes.py : REFUSÉ
OK  les deux appels séparés entre deux métiers : REFUSÉ
OK  les deux appels hors de pc-lourd : REFUSÉ
OK  workflow complet (rust + front + bancs) : ACCEPTÉ
OK  métiers lus : ['rust', 'front', 'bancs']
OK  runs-on lu : ['pc-lourd', 'pc-lourd', 'pc-lourd']
OK  .forgejo/workflows/tableau.yml : les métiers `rust` appellent `controle/bancs_concernes.py`
    et `_tableau/lancer-tests.py` sur `pc-lourd`.
OK  _tableau/test_garde_ci.py est dans le jeu du lanceur (195 bancs).
OK  le choix retient _tableau/test_garde_ci.py quand .forgejo/workflows/tableau.yml est touché
    (tout=False).
rc=0        (0,25 s)

Rouge quand l'étape est retirée, sur le workflow réel (copie locale, restaurée ensuite par
git checkout) :

== a) `_tableau/lancer-tests.py` retiré du workflow réel : rc=1
   .forgejo/workflows/tableau.yml : aucun métier sur `pc-lourd` n'appelle
   `controle/bancs_concernes.py` ET `_tableau/lancer-tests.py` — métiers mesurés :
   rust (bancs_concernes=oui, lancer-tests=NON), front (bancs_concernes=NON, lancer-tests=NON)
== b) `controle/bancs_concernes.py` retiré du workflow réel : rc=1
== c) les deux appels retirés : rc=1
== workflow restauré : git diff --quiet -> 0

Rouge quand la sélection du banc est retirée (l'inscription BALAYEURS en moins) :

== inscription BALAYEURS retirée : rc=1
   ÉCHEC le choix retient _tableau/test_garde_ci.py quand .forgejo/workflows/tableau.yml est
   touché (tout=False).
== restauré : git diff --quiet -> 0

Le banc passe par la porte et par ses voisins :

$ python3 _tableau/lancer-tests.py --sans-couverture _tableau/test_garde_ci.py
ok    _tableau/test_garde_ci.py
1 banc(s) verts.
$ python3 controle/test_bancs_concernes.py
... ÉCARTS : aucun   (rc=0)
$ python3 _tableau/test_lanceur_porte_1185.py
OK : les deux bancs de STUD-1185 passent par le lanceur, un échec bloque le déploiement  (rc=0)
$ cd _tableau/rust && cargo test --release --locked
5 binaires, tous `test result: ok`, 0 échec (RC_TEST=0) ; cargo build --release --locked : rc=0

Comment le banc tourne (voie B, et pourquoi pas la voie A)

lancer-tests.py --tout passe tous les test_*.py de _tableau/ : l'étape de la porte, dans le
workflow (ligne 214), le joue donc sur chaque branche sans qu'aucune étape du workflow ait à le
nommer. La voie A (une étape qui l'appelle) ne pouvait pas exister : cette étape serait
retirable, et c'est exactement ce que le banc garde.

.forgejo/workflows/* est en plus inscrit dans BALAYEURS de controle/bancs_concernes.py : le
choix le retient quand le workflow est touché, et livrer.sh passe ces entrées _tableau/ au
lanceur — la porte locale le joue donc aussi quand le workflow bouge. Dans l'étape de la CI, la
boucle des bancs choisis ne retient que les entrées controle/ (ligne 352) : l'entrée _tableau/
y est sans effet, le --tout de la ligne 214 couvrant déjà ce banc.

Le banc mesure ces deux choses lui-même (sa place dans le jeu du lanceur, sa sélection par le
choix), donc une garde qui ne tourne plus se plaint au lieu de passer pour verte.

Ce que le banc ne mesure pas

Que le choix alimente le passage : il mesure les deux appels dans un même métier pc-lourd, pas
que la sortie de bancs_concernes.py nourrit lancer-tests.py. Et la place du banc dans le jeu du
lanceur n'est pas éprouvée par un cas fabriqué (retirer une entrée de BALAYEURS l'est).

Constat, hors du périmètre de cette PR

main n'a pas de métier bancs. La PR #1638 (STUD-1185, « passer les bancs Python concernés »)
ne le porte plus : sa branche hermes/ci-bancs-concernes pointe sur 3aa06e4a, un ancêtre de
main, donc son diff est vide (état mesuré le 2026-10-15 : open, mergeable=true). La garde
tient aujourd'hui par le métier rust, qui appelle les deux dans deux étapes séparées (le jeu
complet lancer-tests.py --tout, ligne 214, et le choix bancs_concernes.py, ligne 341). Le banc
nomme le métier qui tient la garde au lieu de supposer le nom bancs : le jour où un métier dédié
revient, le message changera tout seul.

## Ce que fait cette PR Un banc de garde : `_tableau/test_garde_ci.py` lit `.forgejo/workflows/tableau.yml` et sort 1 si aucun métier tournant sur `pc-lourd` n'appelle à la fois `controle/bancs_concernes.py` (le choix des bancs concernés) et `_tableau/lancer-tests.py` (leur passage). Pourquoi : rien ne gardait cette chaîne. La retirer du workflow ne faisait rougir aucune porte — la CI repassait Rust et Svelte comme avant, et le refus d'un onglet habillé ne revenait qu'au `deploy-132.sh`, après fusion. ## Mesures (2026-10-15, branche 81fca6af) $ python3 _tableau/test_garde_ci.py ; echo rc=$? OK workflow sans métier bancs (rust + front seuls) : REFUSÉ OK métier bancs sans lancer-tests.py : REFUSÉ OK métier bancs sans bancs_concernes.py : REFUSÉ OK les deux appels séparés entre deux métiers : REFUSÉ OK les deux appels hors de pc-lourd : REFUSÉ OK workflow complet (rust + front + bancs) : ACCEPTÉ OK métiers lus : ['rust', 'front', 'bancs'] OK runs-on lu : ['pc-lourd', 'pc-lourd', 'pc-lourd'] OK .forgejo/workflows/tableau.yml : les métiers `rust` appellent `controle/bancs_concernes.py` et `_tableau/lancer-tests.py` sur `pc-lourd`. OK _tableau/test_garde_ci.py est dans le jeu du lanceur (195 bancs). OK le choix retient _tableau/test_garde_ci.py quand .forgejo/workflows/tableau.yml est touché (tout=False). rc=0 (0,25 s) Rouge quand l'étape est retirée, sur le workflow réel (copie locale, restaurée ensuite par `git checkout`) : == a) `_tableau/lancer-tests.py` retiré du workflow réel : rc=1 .forgejo/workflows/tableau.yml : aucun métier sur `pc-lourd` n'appelle `controle/bancs_concernes.py` ET `_tableau/lancer-tests.py` — métiers mesurés : rust (bancs_concernes=oui, lancer-tests=NON), front (bancs_concernes=NON, lancer-tests=NON) == b) `controle/bancs_concernes.py` retiré du workflow réel : rc=1 == c) les deux appels retirés : rc=1 == workflow restauré : git diff --quiet -> 0 Rouge quand la sélection du banc est retirée (l'inscription `BALAYEURS` en moins) : == inscription BALAYEURS retirée : rc=1 ÉCHEC le choix retient _tableau/test_garde_ci.py quand .forgejo/workflows/tableau.yml est touché (tout=False). == restauré : git diff --quiet -> 0 Le banc passe par la porte et par ses voisins : $ python3 _tableau/lancer-tests.py --sans-couverture _tableau/test_garde_ci.py ok _tableau/test_garde_ci.py 1 banc(s) verts. $ python3 controle/test_bancs_concernes.py ... ÉCARTS : aucun (rc=0) $ python3 _tableau/test_lanceur_porte_1185.py OK : les deux bancs de STUD-1185 passent par le lanceur, un échec bloque le déploiement (rc=0) $ cd _tableau/rust && cargo test --release --locked 5 binaires, tous `test result: ok`, 0 échec (RC_TEST=0) ; cargo build --release --locked : rc=0 ## Comment le banc tourne (voie B, et pourquoi pas la voie A) `lancer-tests.py --tout` passe tous les `test_*.py` de `_tableau/` : l'étape de la porte, dans le workflow (ligne 214), le joue donc sur chaque branche **sans qu'aucune étape du workflow ait à le nommer**. La voie A (une étape qui l'appelle) ne pouvait pas exister : cette étape serait retirable, et c'est exactement ce que le banc garde. `.forgejo/workflows/*` est en plus inscrit dans `BALAYEURS` de `controle/bancs_concernes.py` : le choix le retient quand le workflow est touché, et `livrer.sh` passe ces entrées `_tableau/` au lanceur — la porte locale le joue donc aussi quand le workflow bouge. Dans l'étape de la CI, la boucle des bancs choisis ne retient que les entrées `controle/` (ligne 352) : l'entrée `_tableau/` y est sans effet, le `--tout` de la ligne 214 couvrant déjà ce banc. Le banc mesure ces deux choses lui-même (sa place dans le jeu du lanceur, sa sélection par le choix), donc une garde qui ne tourne plus se plaint au lieu de passer pour verte. ## Ce que le banc ne mesure pas Que le choix alimente le passage : il mesure les deux appels dans un même métier `pc-lourd`, pas que la sortie de `bancs_concernes.py` nourrit `lancer-tests.py`. Et la place du banc dans le jeu du lanceur n'est pas éprouvée par un cas fabriqué (retirer une entrée de `BALAYEURS` l'est). ## Constat, hors du périmètre de cette PR `main` n'a **pas** de métier `bancs`. La PR #1638 (STUD-1185, « passer les bancs Python concernés ») ne le porte plus : sa branche `hermes/ci-bancs-concernes` pointe sur `3aa06e4a`, un ancêtre de `main`, donc son diff est vide (état mesuré le 2026-10-15 : `open`, `mergeable=true`). La garde tient aujourd'hui par le métier `rust`, qui appelle les deux dans deux étapes séparées (le jeu complet `lancer-tests.py --tout`, ligne 214, et le choix `bancs_concernes.py`, ligne 341). Le banc nomme le métier qui tient la garde au lieu de supposer le nom `bancs` : le jour où un métier dédié revient, le message changera tout seul.

hermes-bot added 1 commit 2026-10-15 16:31:30 +02:00

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

Cause. Rien ne gardait la chaîne qui passe les bancs Python du tableau dans la CI : la
retirer du workflow ne faisait rougir aucune porte, elle repassait Rust et Svelte comme
avant, et le refus d'un onglet habillé ne revenait qu'au `deploy-132.sh`, après fusion.

Remède. `_tableau/test_garde_ci.py` lit `.forgejo/workflows/tableau.yml` (lecture par
indentation, sans PyYAML) et sort 1 si aucun métier tournant sur `pc-lourd` n'appelle à la
fois `controle/bancs_concernes.py` (le choix des bancs concernés) et
`_tableau/lancer-tests.py` (leur passage). Six cas fabriqués dans une aire de jeu prouvent
le refus : métier retiré, un appel retiré (de chaque côté), les deux appels séparés entre
deux métiers, les deux appels hors de `pc-lourd`. Le banc nomme le ou les métiers qui
tiennent la garde : il ne suppose pas leur nom.

Sélection du banc, voie B. `.forgejo/workflows/*` est inscrit dans `BALAYEURS` de
`controle/bancs_concernes.py` : toucher le workflow fait passer ce banc par la porte. La
voie A (le banc appelé par une étape du workflow lui-même) ne peut pas exister pour une
garde qui juge ce workflow : la retirer suffirait à faire taire la garde.

Mesure du 2026-10-15. `main` n'a pas de métier `bancs` — la PR #1638 (STUD-1185) ne le
porte plus, sa tête est un ancêtre de `main` et son diff est vide. La garde tient par le
métier `rust`, qui appelle les deux dans deux étapes séparées (le jeu complet
`lancer-tests.py --tout`, et le choix `bancs_concernes.py` pour les bancs de `controle/`).
Le banc le dit, et dit aussi ce qu'il ne mesure pas : que le choix alimente le passage.

hermes-bot force-pushed hermes/banc-garde-ci-tableau from f9e1de9088 to 81fca6af35 2026-10-15 16:37:43 +02:00 Compare

hermes-fusion merged commit f93bca9731 into main 2026-10-15 16:55:03 +02:00

hermes-fusion deleted branch hermes/banc-garde-ci-tableau 2026-10-15 16:55:04 +02:00

hermes-fusion commented 2026-10-15 16:55:04 +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 16:55:05 +02:00

Merge pull request 'Garde de la CI du tableau : un banc refuse le workflow sans les bancs du tableau' (#1738) from hermes/banc-garde-ci-tableau into main

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!1738

No description provided.