Déploiement du 132 : un commit dépassé par main sort en vert, sans issue (issue #1659) #1668

Merged

hermes-fusion merged 1 commit from hermes/depassement-132 into main 2026-10-15 07:40:34 +02:00

Conversation 2 Commits 1 Files changed 4 +128 -13

hermes-bot commented 2026-10-14 22:46:15 +02:00

Collaborator

• Copy link
• Copy Markdown

Correctif de l'issue #1659, à poser sur la branche de #1626 : le workflow et deployer-fusion.sh n'existent que là, donc cette PR a pour base hermes/deploiement-auto-132 et son diff ne contient que le commit 81056966 (rien de la livraison de #1626 n'est repris ici). Pour la faire partir dans main : fusionner cette PR dans la branche, ou git cherry-pick 81056966 dessus ; le chef décide.

Cause. Deux fusions qui se suivent : la copie de l'exécutant n'est plus main, deploy-132.sh refuse (à raison) de poser un code qui n'est pas celui de main, et le déploiement sortait en ROUGE en ouvrant l'issue « Déploiement 132 en échec » (runs 10596 et 10597). Le déploiement du python mourait sur ce refus avant d'écrire sa cause : l'issue ne disait que « le déploiement n'a pas abouti », la raison exacte était coupée.

Remède.

1. concurrency : cancel-in-progress: true — un seul déploiement à la fois, la fusion la plus récente annule celle qui l'a précédée.
2. deployer-fusion.sh relit origin/main avant de toucher au 132 : commit dépassé, sortie 0 avec « dépassé par , le déploiement suivant s'en charge ». Rien n'est touché (pas même la mise de côté), aucune issue ne s'ouvre. Un git fetch qui échoue ne conclut PAS au dépassement : deploy-132.sh tranchera, et son refus reste un échec.
3. La cause citée dans l'issue est celle du journal : la ligne CAUSE : …, sinon la dernière ligne !! … (le refus, nommément). Une exécution qui n'a rien déployé ne ferme plus l'issue ouverte.

Bancs (_tableau/lancer-tests.py --sans-couverture). _tableau/test_deployer_fusion.py (cas 7, commit dépassé) et _tableau/test_workflow_deploiement.py (concurrency, dépassement, cause du refus) reproduisent la panne avant le correctif : 2 échecs et 5 échecs mesurés sur la version d'avant, verts après. cargo test --release --locked : 38 tests, test result: ok ; cargo build --release --locked : 0 avertissement.

Mesuré sur la vraie forge (dispatch du workflow sur cette branche, exécution 10629, tâche 10571, exécutant pc-studio) : le travail sort vert —
DÉPASSÉ — le commit 81056966c893 n'est plus la tête de main : dépassé par 3b006a30b9fc, le déploiement suivant s'en charge
RIEN N'A ÉTÉ TOUCHÉ — le 132 garde ce qu'il sert, et ce n'est pas un échec : aucune issue ne s'ouvre
et l'issue #1659 reste ouverte, sans nouveau commentaire (aucun déploiement n'a eu lieu, c'est le suivant qui la fermera).

Ce qui n'est pas mesuré : un déploiement réel qui atteint « PAGE BONNE » et ferme #1659. Il faut pour cela que le workflow soit dans main, donc que #1626 soit fusionnée : je ne fusionne pas, et je ne déploie pas à la main sur le 132. L'essai de bout en bout se fera à la première poussée dans main après la fusion (l'issue #1659 se ferme alors d'elle-même).

Correctif de l'issue #1659, **à poser sur la branche de #1626** : le workflow et `deployer-fusion.sh` n'existent que là, donc cette PR a pour base `hermes/deploiement-auto-132` et son diff ne contient que le commit `81056966` (rien de la livraison de #1626 n'est repris ici). Pour la faire partir dans `main` : fusionner cette PR **dans la branche**, ou `git cherry-pick 81056966` dessus ; le chef décide. **Cause.** Deux fusions qui se suivent : la copie de l'exécutant n'est plus `main`, `deploy-132.sh` refuse (à raison) de poser un code qui n'est pas celui de `main`, et le déploiement sortait en ROUGE en ouvrant l'issue « Déploiement 132 en échec » (runs 10596 et 10597). Le déploiement du python mourait sur ce refus avant d'écrire sa cause : l'issue ne disait que « le déploiement n'a pas abouti », la raison exacte était coupée. **Remède.** 1. `concurrency` : `cancel-in-progress: true` — un seul déploiement à la fois, la fusion la plus récente annule celle qui l'a précédée. 2. `deployer-fusion.sh` relit `origin/main` avant de toucher au 132 : commit dépassé, sortie 0 avec « dépassé par <sha>, le déploiement suivant s'en charge ». Rien n'est touché (pas même la mise de côté), aucune issue ne s'ouvre. Un `git fetch` qui échoue ne conclut PAS au dépassement : `deploy-132.sh` tranchera, et son refus reste un échec. 3. La cause citée dans l'issue est celle du journal : la ligne `CAUSE : …`, sinon la dernière ligne `!! …` (le refus, nommément). Une exécution qui n'a rien déployé ne ferme plus l'issue ouverte. **Bancs** (`_tableau/lancer-tests.py --sans-couverture`). `_tableau/test_deployer_fusion.py` (cas 7, commit dépassé) et `_tableau/test_workflow_deploiement.py` (concurrency, dépassement, cause du refus) **reproduisent la panne avant le correctif** : 2 échecs et 5 échecs mesurés sur la version d'avant, verts après. `cargo test --release --locked` : 38 tests, `test result: ok` ; `cargo build --release --locked` : 0 avertissement. **Mesuré sur la vraie forge** (dispatch du workflow sur cette branche, exécution 10629, tâche 10571, exécutant `pc-studio`) : le travail sort **vert** — `DÉPASSÉ — le commit 81056966c893 n'est plus la tête de main : dépassé par 3b006a30b9fc, le déploiement suivant s'en charge` `RIEN N'A ÉTÉ TOUCHÉ — le 132 garde ce qu'il sert, et ce n'est pas un échec : aucune issue ne s'ouvre` et l'issue #1659 reste ouverte, sans nouveau commentaire (aucun déploiement n'a eu lieu, c'est le suivant qui la fermera). **Ce qui n'est pas mesuré** : un déploiement réel qui atteint « PAGE BONNE » et ferme #1659. Il faut pour cela que le workflow soit dans `main`, donc que #1626 soit fusionnée : je ne fusionne pas, et je ne déploie pas à la main sur le 132. L'essai de bout en bout se fera à la première poussée dans `main` après la fusion (l'issue #1659 se ferme alors d'elle-même).

hermes-bot added 1 commit 2026-10-14 22:46:15 +02:00

Déploiement du 132 : un commit dépassé par main sort en vert, sans issue ... 81056966c8

Cause. Deux fusions qui se suivent : la copie de l'exécutant n'est plus `main`,
`deploy-132.sh` refuse (à raison) de poser un code qui n'est pas celui de `main`, et le
déploiement sortait en ROUGE en ouvrant l'issue « Déploiement 132 en échec » (issue #1659,
runs 10596 et 10597). Le déploiement du python mourait sur ce refus avant d'écrire sa
cause : l'issue ne disait que « le déploiement n'a pas abouti », la raison exacte était
coupée.

Remède. (1) `concurrency: cancel-in-progress: true` : un seul déploiement à la fois, la
fusion la plus récente annule celle qui l'a précédée. (2) `deployer-fusion.sh` relit
`origin/main` avant de toucher au 132 : commit dépassé, sortie 0 avec « dépassé par <sha>,
le déploiement suivant s'en charge », rien n'est touché (pas même la mise de côté), aucune
issue ; un `git fetch` qui échoue ne conclut PAS au dépassement. (3) La cause citée dans
l'issue est celle du journal : la ligne `CAUSE : …`, sinon la dernière ligne `!! …` (le
refus, nommément). Une exécution qui n'a rien déployé ne ferme plus l'issue ouverte.

Bancs. `_tableau/test_deployer_fusion.py` (cas 7) et `_tableau/test_workflow_deploiement.py`
(concurrency, dépassement, cause du refus) reproduisent la panne avant le correctif — 2 et
5 échecs mesurés sur la version d'avant — et passent après. Leçon datée dans LECONS.md.

hermes-bot referenced this pull request 2026-10-14 22:55:29 +02:00

Déploiement 132 en échec #1659

hermes-bot referenced this pull request 2026-10-14 22:55:49 +02:00

Déploiement du 132 après chaque fusion, depuis la forge, sans le LXC 130 #1626

hermes-bot referenced this pull request 2026-10-14 23:34:11 +02:00

Déploiement du 132 après chaque fusion, depuis la forge, sans le LXC 130 #1626

hermes-fusion changed target branch from hermes/deploiement-auto-132 to main 2026-10-15 00:05:04 +02:00

hermes-fusion added the

conflit

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

hermes-fusion commented 2026-10-15 00:10:02 +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/depassement-132 from 81056966c8 to cc7b9bd254 2026-10-15 02:02:55 +02:00 Compare

hermes-fusion removed the

conflit

label 2026-10-15 02:05:04 +02:00

hermes-fusion merged commit 5c729f53b5 into main 2026-10-15 07:40:34 +02:00

hermes-fusion deleted branch hermes/depassement-132 2026-10-15 07:40:34 +02:00

hermes-fusion commented 2026-10-15 07:40:34 +02:00

Collaborator

• Copy link
• Copy Markdown

Fusionnée automatiquement par fusion-auto (forge) : CI verte (Rust et Front Svelte), PR relue (étiquette relu), sans conflit.

Fusionnée automatiquement par `fusion-auto` (forge) : CI verte (Rust et Front Svelte), PR relue (étiquette `relu`), sans conflit.

hermes-fusion referenced this pull request from a commit 2026-10-15 07:40:36 +02:00

Merge pull request 'Déploiement du 132 : un commit dépassé par main sort en vert, sans issue (issue #1659)' (#1668) from hermes/depassement-132 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!1668

No description provided.