ci: move check-frontend, audit and release from Node 20 to Node 24 #414

Merged

maximus merged 2 commits from issue-376-node24 into main 2026-10-12 19:32:20 +00:00

Conversation 3 Commits 2 Files changed 7 +52 -14

maximus commented 2026-10-10 23:42:03 +00:00

Owner

Copy link

Resolves #376

Generated autonomously by /autopilot run of 2026-10-10

Premier maillon de la pile #376 → #345 → #320 → #358, basé sur main 87920ec.

Ce qui change

• check-frontend.yml, audit.yml, release.yml : Node.js 20 (fin de vie le 2026-04-30) → Node.js 24, par deb.nodesource.com/setup_24.x, comme check-rust.yml depuis #375. L'étape s'appelle « Install Node.js 24 » dans check-frontend et audit. Dans release.yml, l'étape « Install base tools and runtimes » garde son nom (elle installe aussi les outils de base et Rust) : seul son commentaire change. node --version reste dans les trois journaux.
• Commentaire concurrency de check-rust.yml réécrit d'après la-compagnie-maximus/docs/forgejo-ops.md (mesure du 2026-10-02 sur Forgejo 8.0.3) : la clé passe la validation de schéma mais son apport n'a pas été isolé, Forgejo annule sans elle un run push remplacé, et aucun job pull_request n'a été annulé par un run suivant. Les clés restent (D2), avec la raison écrite. check-frontend.yml et audit.yml renvoient à ce commentaire.
• Risque NodeSource nommé (caveat sécurité) : dans release.yml, le script tourne en root dans le conteneur, dont le Node.js lance ensuite npx tauri build avec TAURI_SIGNING_PRIVATE_KEY. Gardé, sans tarball épinglé (décision de Max). Même constat dans docs/architecture.md.
• docs/architecture.md, section release.yml : « Deux jobs (build-windows en windows-latest, build-linux en ubuntu-22.04) » était faux. Corrigé : un seul job build-and-release en conteneur ubuntu:22.04, Windows compilé depuis Linux par cargo-xwin.
• Skill /release, étape 9 : lire node --version dans le journal du run de release (commande rejouée sur le run 508).
• STATE.md : nouvelle puce « Vérifications dues à la prochaine release » dans « Blockers actifs », avec release.yml sous Node 24.
• Pas d'entrée CHANGELOG (CI seulement). CLAUDE.md inchangé : sa section CI/CD ne cite aucune version de Node, et sa phrase npm audit périmée relève de #358 (critère explicite de ce maillon).

Technique

• Node 24 embarque npm 11 : npm ci doit lire le lock actuel, généré par npm 10 (lockfileVersion 3). Le run check-frontend de cette PR le prouve. #358 s'appuie dessus : son lock sera généré et lu par npm 11.
• actions/checkout@v4 déclare node20 ; le runner le lance avec le node du conteneur, Node 24 compris (prouvé par check-rust depuis #375). Le commentaire de check-rust.yml qui le dit reste exact.
• Hors périmètre, laissé tel quel : .github/workflows/check.yml (miroir GitHub dormant) épingle aussi node-version: '20', mais il n'est pas dans les fichiers planifiés, et docs/architecture.md le dit « laissé tel quel ».
• Aucun changement de schéma dans release.yml : la modification tient dans le bloc run: (commentaire et URL), donc rien que le validateur du runner puisse refuser au prochain tag.

Preuves

Contrôles locaux :

• grep -rn setup_20 .forgejo/workflows/ : vide.
• Les quatre workflows se parsent en YAML (PyYAML 6.0.1, yaml.safe_load) ; leur première étape installe setup_24.x.
• Référence avant changement, lue dans les journaux : v20.20.2 dans check-frontend (run 507), audit (run 510) et release (run 508). Motif : grep -E 'Z v[0-9]+\.[0-9]+\.[0-9]+\s*$', une seule ligne par journal.
• Lignes ajoutées scannées (dépôt public) : aucune donnée personnelle, aucun secret.

Runs CI à lire (journal par la route web /maximus/Simpl-Resultat/actions/runs/<n>/jobs/0/logs) :

• audit sur la branche, déclenché par POST /actions/workflows/audit.yml/dispatches {"ref":"issue-376-node24"} → HTTP 204, run 511 (workflow_dispatch, 71a4e1e). Vert, lu dans le journal : node --version = v24.21.0, 666 crates scannées, « 12 allowed warnings found » (même compte qu'avant), 🏁 Job succeeded. L'avertissement couldn't update crates.io index figurait déjà dans le run 510 sous Node 20.
• check-frontend sur 71a4e1e : run 512, vert en 1 min 51 s, lu dans le journal : node --version = v24.21.0, npm 11.19.0, npm ci (175 paquets en 11 s), build vite, 109 fichiers et 1904 tests verts, 🏁 Job succeeded.
• check-rust sur 71a4e1e : run 513 (déclenché parce que check-rust.yml change), attendu vert ; Node y était déjà en 24.
• Sur la tête f19b027 (correctif d'auto-revue : skill /release et un commentaire, voir le commentaire d'auto-revue) : check-frontend run 514, check-rust run 515, à lire. Les runs de PR ne s'annulent pas entre eux (mesure de forgejo-ops.md), donc 512 et 513 vont aussi au bout.

Observation sous npm 11 (run 512, absente du run 507 sous npm 10) : npm warn install-scripts 1 package has install scripts not yet covered by allowScripts: esbuild@0.25.12 (postinstall: node install.js). Sans effet aujourd'hui : le build vite, qui passe par esbuild, et les tests sont verts. esbuild est le seul paquet du lock à script d'installation sur Linux (fsevents est optionnel, macOS). Si une version future de npm bloque ce script par défaut, c'est là que ça se verra ; à garder en tête pour #358, dont le lock sera généré par npm 11.

Ce qui ne se prouve qu'au prochain tag

release.yml n'est exercé qu'au tag, d'où Resolves avec la vérification consignée. Son build frontend est déjà couvert : beforeBuildCommand vaut npm run build, la commande que le run 512 a passée sous Node 24. Restent propres au tag la CLI Tauri (npx tauri build) sous Node 24, cargo-xwin et la publication :

• node --version du run de release en v24.x (commande à l'étape 9 du skill /release) ;
• verify-release.sh vert (7 artefacts, latest.json).

Le diff touchant release.yml, l'étape 10 de /release (cycle réel de mise à jour) s'applique aussi, selon la règle du skill. Les deux points sont notés dans STATE.md.

Pour relire en priorité

1. Le commentaire concurrency de check-rust.yml, contre forgejo-ops.md (sections « Le schéma du workflow est validé par le runner » et « Un push annule le run du push précédent »). La raison de garder les clés ne dit pas que le miroir GitHub lit ces fichiers : GitHub ne lit que .github/workflows/.
2. La note de confiance de release.yml et le paragraphe de docs/architecture.md. La phrase sur rustup (même situation que NodeSource) est un ajout du worker, hors caveat : à garder ou à retirer.
3. La correction « Deux jobs » → un seul job dans docs/architecture.md, à comparer à release.yml.

🤖 Generated with Claude Code

Resolves #376 Generated autonomously by /autopilot run of 2026-10-10 > Premier maillon de la pile #376 → #345 → #320 → #358, basé sur `main` `87920ec`. ## Ce qui change - `check-frontend.yml`, `audit.yml`, `release.yml` : Node.js 20 (fin de vie le 2026-04-30) → Node.js 24, par `deb.nodesource.com/setup_24.x`, comme `check-rust.yml` depuis #375. L'étape s'appelle « Install Node.js 24 » dans `check-frontend` et `audit`. Dans `release.yml`, l'étape « Install base tools and runtimes » garde son nom (elle installe aussi les outils de base et Rust) : seul son commentaire change. `node --version` reste dans les trois journaux. - Commentaire `concurrency` de `check-rust.yml` réécrit d'après `la-compagnie-maximus/docs/forgejo-ops.md` (mesure du 2026-10-02 sur Forgejo 8.0.3) : la clé passe la validation de schéma mais son apport n'a pas été isolé, Forgejo annule sans elle un run `push` remplacé, et aucun job `pull_request` n'a été annulé par un run suivant. Les clés restent (D2), avec la raison écrite. `check-frontend.yml` et `audit.yml` renvoient à ce commentaire. - Risque NodeSource nommé (caveat sécurité) : dans `release.yml`, le script tourne en root dans le conteneur, dont le Node.js lance ensuite `npx tauri build` avec `TAURI_SIGNING_PRIVATE_KEY`. Gardé, sans tarball épinglé (décision de Max). Même constat dans `docs/architecture.md`. - `docs/architecture.md`, section `release.yml` : « Deux jobs (build-windows en windows-latest, build-linux en ubuntu-22.04) » était faux. Corrigé : un seul job `build-and-release` en conteneur `ubuntu:22.04`, Windows compilé depuis Linux par `cargo-xwin`. - Skill `/release`, étape 9 : lire `node --version` dans le journal du run de release (commande rejouée sur le run 508). - `STATE.md` : nouvelle puce « Vérifications dues à la prochaine release » dans « Blockers actifs », avec `release.yml` sous Node 24. - Pas d'entrée CHANGELOG (CI seulement). `CLAUDE.md` inchangé : sa section CI/CD ne cite aucune version de Node, et sa phrase `npm audit` périmée relève de #358 (critère explicite de ce maillon). ## Technique - Node 24 embarque npm 11 : `npm ci` doit lire le lock actuel, généré par npm 10 (`lockfileVersion` 3). Le run `check-frontend` de cette PR le prouve. #358 s'appuie dessus : son lock sera généré et lu par npm 11. - `actions/checkout@v4` déclare `node20` ; le runner le lance avec le `node` du conteneur, Node 24 compris (prouvé par `check-rust` depuis #375). Le commentaire de `check-rust.yml` qui le dit reste exact. - Hors périmètre, laissé tel quel : `.github/workflows/check.yml` (miroir GitHub dormant) épingle aussi `node-version: '20'`, mais il n'est pas dans les fichiers planifiés, et `docs/architecture.md` le dit « laissé tel quel ». - Aucun changement de schéma dans `release.yml` : la modification tient dans le bloc `run:` (commentaire et URL), donc rien que le validateur du runner puisse refuser au prochain tag. ## Preuves Contrôles locaux : - `grep -rn setup_20 .forgejo/workflows/` : vide. - Les quatre workflows se parsent en YAML (PyYAML 6.0.1, `yaml.safe_load`) ; leur première étape installe `setup_24.x`. - Référence avant changement, lue dans les journaux : `v20.20.2` dans `check-frontend` (run 507), `audit` (run 510) et `release` (run 508). Motif : `grep -E 'Z v[0-9]+\.[0-9]+\.[0-9]+\s*$'`, une seule ligne par journal. - Lignes ajoutées scannées (dépôt public) : aucune donnée personnelle, aucun secret. Runs CI à lire (journal par la route web `/maximus/Simpl-Resultat/actions/runs/<n>/jobs/0/logs`) : - `audit` sur la branche, déclenché par `POST /actions/workflows/audit.yml/dispatches` `{"ref":"issue-376-node24"}` → **HTTP 204**, run **511** (`workflow_dispatch`, `71a4e1e`). **Vert, lu dans le journal** : `node --version` = `v24.21.0`, 666 crates scannées, « 12 allowed warnings found » (même compte qu'avant), `🏁 Job succeeded`. L'avertissement `couldn't update crates.io index` figurait déjà dans le run 510 sous Node 20. - `check-frontend` sur `71a4e1e` : run **512**, **vert en 1 min 51 s, lu dans le journal** : `node --version` = `v24.21.0`, npm `11.19.0`, `npm ci` (175 paquets en 11 s), build vite, 109 fichiers et 1904 tests verts, `🏁 Job succeeded`. - `check-rust` sur `71a4e1e` : run **513** (déclenché parce que `check-rust.yml` change), attendu vert ; Node y était déjà en 24. - Sur la tête `f19b027` (correctif d'auto-revue : skill `/release` et un commentaire, voir le commentaire d'auto-revue) : `check-frontend` run **514**, `check-rust` run **515**, à lire. Les runs de PR ne s'annulent pas entre eux (mesure de `forgejo-ops.md`), donc 512 et 513 vont aussi au bout. Observation sous npm 11 (run 512, absente du run 507 sous npm 10) : `npm warn install-scripts 1 package has install scripts not yet covered by allowScripts: esbuild@0.25.12 (postinstall: node install.js)`. Sans effet aujourd'hui : le build vite, qui passe par esbuild, et les tests sont verts. `esbuild` est le seul paquet du lock à script d'installation sur Linux (`fsevents` est optionnel, macOS). Si une version future de npm bloque ce script par défaut, c'est là que ça se verra ; à garder en tête pour #358, dont le lock sera généré par npm 11. ## Ce qui ne se prouve qu'au prochain tag `release.yml` n'est exercé qu'au tag, d'où `Resolves` avec la vérification consignée. Son build frontend est déjà couvert : `beforeBuildCommand` vaut `npm run build`, la commande que le run 512 a passée sous Node 24. Restent propres au tag la CLI Tauri (`npx tauri build`) sous Node 24, `cargo-xwin` et la publication : - `node --version` du run de release en `v24.x` (commande à l'étape 9 du skill `/release`) ; - `verify-release.sh` vert (7 artefacts, `latest.json`). Le diff touchant `release.yml`, l'étape 10 de `/release` (cycle réel de mise à jour) s'applique aussi, selon la règle du skill. Les deux points sont notés dans `STATE.md`. ## Pour relire en priorité 1. Le commentaire `concurrency` de `check-rust.yml`, contre `forgejo-ops.md` (sections « Le schéma du workflow est validé par le runner » et « Un push annule le run du push précédent »). La raison de garder les clés ne dit pas que le miroir GitHub lit ces fichiers : GitHub ne lit que `.github/workflows/`. 2. La note de confiance de `release.yml` et le paragraphe de `docs/architecture.md`. La phrase sur `rustup` (même situation que NodeSource) est un ajout du worker, hors caveat : à garder ou à retirer. 3. La correction « Deux jobs » → un seul job dans `docs/architecture.md`, à comparer à `release.yml`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

maximus added 1 commit 2026-10-10 23:42:03 +00:00

ci: move check-frontend, audit and release from Node 20 to Node 24 ... 71a4e1e88f

Node 20 reached end of life on 2026-04-30. check-frontend.yml, audit.yml
and release.yml now install Node.js 24 through NodeSource's setup_24.x,
as check-rust.yml has done since #375. Each step still prints
`node --version` in the job log.

The concurrency comment of check-rust.yml claimed the key cancels
obsolete runs on force-push. la-compagnie-maximus docs/forgejo-ops.md
measured the opposite on Forgejo 8.0.3: no pull_request run was
cancelled by a later one, and push runs are cancelled without the key.
The comment now states that measurement; the keys stay (harmless,
meaningful where honoured), and check-frontend.yml and audit.yml point
to it.

release.yml names the trust it places in NodeSource: the script runs as
root in the job container, whose Node.js then runs `npx tauri build`
with TAURI_SIGNING_PRIVATE_KEY. Kept on purpose, also documented in
docs/architecture.md, whose release.yml section described two jobs
(windows-latest, ubuntu-22.04) where there is one containerised job
cross-compiling Windows with cargo-xwin.

release.yml only runs on a tag, so Node 24 there is proven at the next
release: the /release skill now reads `node --version` from the release
run's log (step 9), and STATE.md lists it under the checks due at the
next release.

No CHANGELOG entry: CI only.

Resolves #376

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

maximus added 1 commit 2026-10-10 23:44:03 +00:00

ci: fix the release run lookup in the /release skill ... f19b027c5d

The /actions/tasks endpoint ignores `limit` and returns the whole list,
newest first, so `?limit=5` promised five rows it does not give. The
skill now selects the release.yml run of the tag directly (python3, as
verify-release.sh does), checked on v0.17.1: run 508, `v20.20.2`.

Also clarify check-frontend.yml's concurrency comment: same setup as
check-rust.yml, not the same group.

Refs #376

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

maximus commented 2026-10-10 23:45:30 +00:00

Author

Owner

Copy link

Auto-revue du worker /autopilot, pas une revue indépendante. Verdict final : APPROVE, après une correction faite pendant la revue (f19b027).

Critères de planification

1. grep -rn setup_20 .forgejo/workflows/ vide : ✅ contrôlé localement sur la tête.
2. Journal check-frontend de la PR sous Node 24 : ✅ run 512 (sur 71a4e1e) : v24.21.0, npm 11.19.0, npm ci, build vite, 109 fichiers et 1904 tests verts. Reste le run 514 sur la tête f19b027, dont le workflow ne diffère que par un commentaire.
3. audit sous Node 24 par workflow_dispatch : ✅ HTTP 204, run 511 : v24.21.0, 666 crates, « 12 allowed warnings found » (même compte qu'avant), 🏁 Job succeeded.
4. Commentaire concurrency conforme à forgejo-ops.md : ✅ relu contre les sections « Le schéma du workflow est validé par le runner » et « Un push annule le run du push précédent ». Clé validée mais apport non isolé ; annulation des runs push sans la clé, job en file comme en cours ; aucun job pull_request/pull_request_sync annulé par un run suivant. Rien n'est affirmé sur schedule et workflow_dispatch, que la doc ne couvre pas.
5. La PR liste ce qui ne se prouve qu'au prochain tag : ✅ section dédiée, reprise dans STATE.md et à l'étape 9 du skill /release.

Caveats

• 🟢 SÉCURITÉ : ✅ risque NodeSource nommé dans release.yml et dans docs/architecture.md : script en root, npx tauri build avec TAURI_SIGNING_PRIVATE_KEY, jetons de publication des étapes suivantes. Gardé, sans tarball épinglé.
• 🟢 TECHNIQUE : ✅ étape 9 du skill /release, commande rejouée sur v0.17.1 (run 508 → v20.20.2).

Sécurité, justesse, conventions

• Aucun secret : le skill lit le jeton par $(cat ~/.forgejo-token). Aucune entrée non fiable interpolée dans un workflow ; les changements de workflow se limitent aux URL NodeSource, aux noms d'étape et à des commentaires. Lignes ajoutées scannées (dépôt public) : rien.
• release.yml : modification limitée au bloc run:, donc aucun risque de rejet de schéma au prochain tag.
• Pas d'entrée CHANGELOG (CI seulement). CLAUDE.md inchangé : aucune version de Node citée, et la phrase npm audit périmée est un critère de #358.

Correction faite pendant la revue (f19b027, Refs #376)

• Le skill citait GET /actions/tasks?limit=5. L'API ignore limit (602 entrées rendues). Remplacé par une sélection directe du run release.yml du tag (python3, comme verify-release.sh), testée sur v0.17.1 : RUN=508, v20.20.2.
• check-frontend.yml : « Same concurrency key » pouvait se lire « même groupe » ; précisé.

Reste à prouver par la CI (lecture par la session principale)

• Runs 513 et 515 (check-rust) : verts attendus ; aucune ligne exécutée ne change, seul le commentaire concurrency.
• Run 514 (check-frontend sur la tête) : vert attendu, même contenu que 512 hors commentaire.
• Au prochain tag : node --version du run de release en v24.x, verify-release.sh vert, et l'étape 10 de /release (le diff touche release.yml).

Points à relire en priorité

1. Le commentaire concurrency de check-rust.yml, et la formulation de la raison D2 (« keeps its GitHub Actions meaning should these workflows run where it is honoured ») : GitHub ne lit que .github/workflows/.
2. La phrase sur rustup dans docs/architecture.md, ajout hors caveat.
3. La correction « Deux jobs » → un seul job dans docs/architecture.md.
4. L'avertissement npm 11 install-scripts sur le postinstall d'esbuild (run 512, absent sous npm 10) : sans effet aujourd'hui, à garder en tête pour #358.

**Auto-revue du worker `/autopilot`, pas une revue indépendante.** Verdict final : **APPROVE**, après une correction faite pendant la revue (`f19b027`). ### Critères de planification 1. `grep -rn setup_20 .forgejo/workflows/` vide : ✅ contrôlé localement sur la tête. 2. Journal `check-frontend` de la PR sous Node 24 : ✅ run **512** (sur `71a4e1e`) : `v24.21.0`, npm `11.19.0`, `npm ci`, build vite, 109 fichiers et 1904 tests verts. Reste le run **514** sur la tête `f19b027`, dont le workflow ne diffère que par un commentaire. 3. `audit` sous Node 24 par `workflow_dispatch` : ✅ HTTP 204, run **511** : `v24.21.0`, 666 crates, « 12 allowed warnings found » (même compte qu'avant), `🏁 Job succeeded`. 4. Commentaire `concurrency` conforme à `forgejo-ops.md` : ✅ relu contre les sections « Le schéma du workflow est validé par le runner » et « Un push annule le run du push précédent ». Clé validée mais apport non isolé ; annulation des runs `push` sans la clé, job en file comme en cours ; aucun job `pull_request`/`pull_request_sync` annulé par un run suivant. Rien n'est affirmé sur `schedule` et `workflow_dispatch`, que la doc ne couvre pas. 5. La PR liste ce qui ne se prouve qu'au prochain tag : ✅ section dédiée, reprise dans `STATE.md` et à l'étape 9 du skill `/release`. ### Caveats - 🟢 SÉCURITÉ : ✅ risque NodeSource nommé dans `release.yml` et dans `docs/architecture.md` : script en root, `npx tauri build` avec `TAURI_SIGNING_PRIVATE_KEY`, jetons de publication des étapes suivantes. Gardé, sans tarball épinglé. - 🟢 TECHNIQUE : ✅ étape 9 du skill `/release`, commande rejouée sur `v0.17.1` (run 508 → `v20.20.2`). ### Sécurité, justesse, conventions - Aucun secret : le skill lit le jeton par `$(cat ~/.forgejo-token)`. Aucune entrée non fiable interpolée dans un workflow ; les changements de workflow se limitent aux URL NodeSource, aux noms d'étape et à des commentaires. Lignes ajoutées scannées (dépôt public) : rien. - `release.yml` : modification limitée au bloc `run:`, donc aucun risque de rejet de schéma au prochain tag. - Pas d'entrée CHANGELOG (CI seulement). `CLAUDE.md` inchangé : aucune version de Node citée, et la phrase `npm audit` périmée est un critère de #358. ### Correction faite pendant la revue (`f19b027`, `Refs #376`) - Le skill citait `GET /actions/tasks?limit=5`. L'API ignore `limit` (602 entrées rendues). Remplacé par une sélection directe du run `release.yml` du tag (python3, comme `verify-release.sh`), testée sur `v0.17.1` : `RUN=508`, `v20.20.2`. - `check-frontend.yml` : « Same concurrency key » pouvait se lire « même groupe » ; précisé. ### Reste à prouver par la CI (lecture par la session principale) - Runs **513** et **515** (`check-rust`) : verts attendus ; aucune ligne exécutée ne change, seul le commentaire `concurrency`. - Run **514** (`check-frontend` sur la tête) : vert attendu, même contenu que 512 hors commentaire. - Au prochain tag : `node --version` du run de release en `v24.x`, `verify-release.sh` vert, et l'étape 10 de `/release` (le diff touche `release.yml`). ### Points à relire en priorité 1. Le commentaire `concurrency` de `check-rust.yml`, et la formulation de la raison D2 (« keeps its GitHub Actions meaning should these workflows run where it is honoured ») : GitHub ne lit que `.github/workflows/`. 2. La phrase sur `rustup` dans `docs/architecture.md`, ajout hors caveat. 3. La correction « Deux jobs » → un seul job dans `docs/architecture.md`. 4. L'avertissement npm 11 `install-scripts` sur le `postinstall` d'`esbuild` (run 512, absent sous npm 10) : sans effet aujourd'hui, à garder en tête pour #358.

maximus added the

autopilot:pending-human

label 2026-10-10 23:45:40 +00:00

maximus commented 2026-10-10 23:55:29 +00:00

Author

Owner

Copy link

CI lue par la session principale du run autopilot (pas une revue)

Run	Workflow	Commit	Résultat	Lu dans le journal
511	audit (workflow_dispatch sur la branche)	71a4e1e	vert	v24.21.0, 666 crates, 12 avertissements autorisés
512	check-frontend	71a4e1e	vert, 1 min 51 s	v24.21.0, npm 11.19.0, npm ci, build vite, 1904 tests (109 fichiers)
513	check-rust	71a4e1e	vert, 4 min 46 s	v24.21.0, garde des suppressions 2 vérifications exit 0, 255 tests Rust
514	check-frontend	f19b027 (tête)	vert, 1 min 54 s	v24.21.0, npm 11.19.0, 1904 tests (109 fichiers)
515	check-rust	f19b027 (tête)	vert, 3 min 41 s	v24.21.0, garde des suppressions exit 0, 255 tests Rust

Nouveau sous npm 11 (run 512 et 514) : npm warn install-scripts … esbuild@0.25.12 (postinstall) not yet covered by allowScripts, absent sous npm 10. Sans effet sur le build ni les tests ; signalé pour #358.

Reste à prouver au prochain tag : release.yml sous Node 24 (voir la section dédiée du corps et la puce de STATE.md).

**CI lue par la session principale du run autopilot (pas une revue)** | Run | Workflow | Commit | Résultat | Lu dans le journal | |---|---|---|---|---| | 511 | audit (`workflow_dispatch` sur la branche) | `71a4e1e` | vert | `v24.21.0`, 666 crates, 12 avertissements autorisés | | 512 | check-frontend | `71a4e1e` | vert, 1 min 51 s | `v24.21.0`, npm `11.19.0`, `npm ci`, build vite, 1904 tests (109 fichiers) | | 513 | check-rust | `71a4e1e` | vert, 4 min 46 s | `v24.21.0`, garde des suppressions 2 vérifications exit 0, 255 tests Rust | | 514 | check-frontend | `f19b027` (tête) | vert, 1 min 54 s | `v24.21.0`, npm `11.19.0`, 1904 tests (109 fichiers) | | 515 | check-rust | `f19b027` (tête) | vert, 3 min 41 s | `v24.21.0`, garde des suppressions exit 0, 255 tests Rust | Nouveau sous npm 11 (run 512 et 514) : `npm warn install-scripts … esbuild@0.25.12 (postinstall) not yet covered by allowScripts`, absent sous npm 10. Sans effet sur le build ni les tests ; signalé pour #358. Reste à prouver au prochain tag : `release.yml` sous Node 24 (voir la section dédiée du corps et la puce de STATE.md).

maximus referenced this pull request 2026-10-11 00:16:04 +00:00

ci: guard the windows-sys 0.61.2 pin in check-rust #415

maximus referenced this pull request 2026-10-11 00:51:35 +00:00

fix: give rpm installs their own key in latest.json #416

maximus referenced this pull request 2026-10-11 01:16:11 +00:00

fix(deps): refresh npm lock to clear 8 advisories #417

maximus commented 2026-10-11 22:31:58 +00:00

Author

Owner

Copy link

Revue indépendante /pr-review (pas l'auto-revue du worker). Verdict : APPROVE

Dans les trois workflows, le passage à Node 24 tient au seul changement d'URL setup_20.x → setup_24.x. Les commentaires et la doc disent ce que mesure forgejo-ops.md et ce que fait release.yml. Aucun bloquant, et la CI de la tête f19b027 est verte, lue dans les journaux.

Vérifié

• Critères de planification, tous tenus :
  • aucun setup_20 dans .forgejo/workflows/ à la tête ;
  • check-frontend sur la tête (run 514) : v24.21.0, npm 11.19.0, npm ci (175 paquets), build vite, 109 fichiers et 1904 tests verts, comme le run 507 sous Node 20 (npm 10.8.2) ;
  • audit par workflow_dispatch (run 511 sur 71a4e1e, fichier inchangé depuis) : v24.21.0, 666 crates, 12 avertissements autorisés, comme le run 510 ;
  • check-rust sur la tête (run 515) : v24.21.0, cache en correspondance exacte, garde rsa vérifiée sur les deux cibles, 255 tests Rust ;
  • ce qui ne se prouve qu'au tag est listé dans la PR, dans STATE.md et à l'étape 9 du skill.
• release.yml ne change rien que le validateur du runner puisse refuser. Les deux versions passées par yaml.safe_load ne diffèrent que par la chaîne run de l'étape 0. Une fois les commentaires retirés, la seule commande changée est l'URL NodeSource, celle que les runs 511 à 515 exécutent dans le même conteneur ubuntu:22.04. bash -n passe sur les trois scripts modifiés. Le build frontend du tag est couvert (beforeBuildCommand vaut npm run build), aucune contrainte engines du lock n'exclut Node 24, et @tauri-apps/cli 2.10.0 déclare >= 10.
• Commentaire concurrency, relu contre les deux sections citées de forgejo-ops.md : il passe la validation de schéma, son apport n'est pas isolé, les runs push sont annulés sans la clé, en file comme en cours (les 22 jobs maximus-api sans clé et les 5 jobs simpl-resultat antérieurs au 2026-04-28), et aucun job pull_request/pull_request_sync n'a été annulé. Conforme. Cette PR en apporte une confirmation directe. f19b027 a été poussé à 23:44:03Z (push non forcé) pendant que check-rust run 513 tournait (démarré à 23:43:56Z). La clé était en place avec cancel-in-progress: true, et le run 513 est allé au bout (vert à 23:48:42Z) au lieu d'être annulé. C'est un cas observé où la clé reste sans effet sur un pull_request_sync, utile à forgejo-ops.md.
• Commande de l'étape 9 du skill /release, extraite du fichier et rejouée : elle rend v20.20.2 pour v0.17.1 (run 508), v0.17.0 et v0.16.0. Un tag inconnu échoue de façon visible (StopIteration, code de sortie 1). Le motif ne trouve qu'une ligne dans chacun des 8 journaux lus (507, 508, 510 à 515), y compris le journal de release de 515 Ko. La sonde sépare donc Node 20 de Node 24 sur le seul workflow que la CI de PR n'exerce pas : c'est l'équivalent de mutation de cette revue.
• docs/architecture.md : la description « un seul job build-and-release en conteneur ubuntu:22.04, Linux puis Windows par cargo-xwin » correspond à release.yml:9-63. La phrase sur les jetons est exacte : GITHUB_TOKEN et PACKAGE_TOKEN servent aux étapes suivantes (release.yml:150 et :221), dans le même conteneur, en root.
• Les commits sont conventionnels (ci:), avec Resolves #376 dans le corps et sur 71a4e1e. La timeline de #376 porte un seul pull_ref en closes, celui de cette PR ; #415 à #417 la citent sans la fermer. Aucun secret ni aucune donnée personnelle dans les lignes ajoutées.

Réponses aux points « à relire en priorité »

1. Le commentaire concurrency ne prête pas au miroir GitHub la lecture de .forgejo/workflows/. La formulation de D2 est corrigée à bon droit.
2. Garder la phrase sur rustup. release.yml:29 est le même curl … | sh en root, et npx tauri build lance cargo avec la clé de signature dans l'environnement, donc aussi les scripts de build de chaque crate. Sans cette phrase, NodeSource passerait pour le seul installeur à qui le job fait confiance.
3. La correction « Deux jobs » → un seul job est exacte (voir plus haut).

Suggestions (non bloquantes)

1. STATE.md:79 : la puce « Backlog ouvert » garde « #376 (status:triage : Node 20 … encore installé par check-frontend.yml et audit.yml …) », que la nouvelle puce du même fichier contredit dès le merge. La mention est toujours là à la tête de la pile (e8306aa, ligne 80). Le journal de décisions du run la laisse au sync post-merge : la vérifier à ce moment-là, ou la retirer ici.
2. src/services/reportService.test.ts:722 dit « CI runs Node 20 → no node:sqlite », ce qui devient faux au merge, puisque Node 24 a node:sqlite. Le changement revient à #392, qui prévoit le harnais node:sqlite et dépend de #376 : corriger le commentaire ici, ou le signaler sur #392.
3. .claude/skills/release/SKILL.md:48, « le paramètre limit y est ignoré » : ce n'est vrai que sans page. Mesuré ce jour : sans paramètre comme avec ?limit=5, 611 lignes ; ?limit=5&page=2 en rend 5 et ?page=2 en rend 30. La commande ne passe ni l'un ni l'autre, elle est donc correcte, mais la parenthèse gagnerait à dire « sans page, la route rend toute la liste ». La même nuance vaut pour le message de f19b027 et pour l'exemple ?limit=5 de forgejo-ops.md (autre dépôt).
4. audit.yml:30-31 renvoie au commentaire de check-rust.yml, qui ne couvre que push et pull_request. Or audit.yml ne tourne que sur schedule et workflow_dispatch, que forgejo-ops.md ne mesure pas. Une demi-ligne dans le renvoi le dirait. Facultatif.

Reste à prouver au prochain tag

Il faudra lire node --version en v24.x dans le journal du run de release et obtenir verify-release.sh vert. L'étape 10 (cycle réel de mise à jour) s'applique aussi, puisque le diff touche release.yml. Tout cela est déjà consigné dans STATE.md et à l'étape 9 du skill.

Actions faites

• La suite n'a pas été rejouée en local : le changement ne touche que la CI, et la CI de la tête est verte dans les journaux (runs 514 et 515). Ce qui a tourné : la commande de l'étape 9 sur trois tags et un tag inconnu, le décompte du motif dans 8 journaux, la comparaison YAML entre main et la tête, bash -n sur les trois scripts, et la mesure de la pagination de /actions/tasks.
• Aucun fichier du dépôt modifié. Les fichiers temporaires /tmp/pr414-* (journaux et script extrait) sont supprimés.
• Label de #376 : status:review → status:approved, posé juste après ce commentaire.

**Revue indépendante `/pr-review` (pas l'auto-revue du worker). Verdict : APPROVE** Dans les trois workflows, le passage à Node 24 tient au seul changement d'URL `setup_20.x` → `setup_24.x`. Les commentaires et la doc disent ce que mesure `forgejo-ops.md` et ce que fait `release.yml`. Aucun bloquant, et la CI de la tête `f19b027` est verte, lue dans les journaux. ### Vérifié - **Critères de planification**, tous tenus : - aucun `setup_20` dans `.forgejo/workflows/` à la tête ; - `check-frontend` sur la tête (run 514) : `v24.21.0`, npm `11.19.0`, `npm ci` (175 paquets), build vite, 109 fichiers et 1904 tests verts, comme le run 507 sous Node 20 (npm `10.8.2`) ; - `audit` par `workflow_dispatch` (run 511 sur `71a4e1e`, fichier inchangé depuis) : `v24.21.0`, 666 crates, 12 avertissements autorisés, comme le run 510 ; - `check-rust` sur la tête (run 515) : `v24.21.0`, cache en correspondance exacte, garde `rsa` vérifiée sur les deux cibles, 255 tests Rust ; - ce qui ne se prouve qu'au tag est listé dans la PR, dans `STATE.md` et à l'étape 9 du skill. - **`release.yml` ne change rien que le validateur du runner puisse refuser.** Les deux versions passées par `yaml.safe_load` ne diffèrent que par la chaîne `run` de l'étape 0. Une fois les commentaires retirés, la seule commande changée est l'URL NodeSource, celle que les runs 511 à 515 exécutent dans le même conteneur `ubuntu:22.04`. `bash -n` passe sur les trois scripts modifiés. Le build frontend du tag est couvert (`beforeBuildCommand` vaut `npm run build`), aucune contrainte `engines` du lock n'exclut Node 24, et `@tauri-apps/cli` 2.10.0 déclare `>= 10`. - **Commentaire `concurrency`**, relu contre les deux sections citées de `forgejo-ops.md` : il passe la validation de schéma, son apport n'est pas isolé, les runs `push` sont annulés sans la clé, en file comme en cours (les 22 jobs `maximus-api` sans clé et les 5 jobs `simpl-resultat` antérieurs au 2026-04-28), et aucun job `pull_request`/`pull_request_sync` n'a été annulé. Conforme. **Cette PR en apporte une confirmation directe.** `f19b027` a été poussé à 23:44:03Z (push non forcé) pendant que `check-rust` run 513 tournait (démarré à 23:43:56Z). La clé était en place avec `cancel-in-progress: true`, et le run 513 est allé au bout (vert à 23:48:42Z) au lieu d'être annulé. C'est un cas observé où la clé reste sans effet sur un `pull_request_sync`, utile à `forgejo-ops.md`. - **Commande de l'étape 9 du skill `/release`**, extraite du fichier et rejouée : elle rend `v20.20.2` pour v0.17.1 (run 508), v0.17.0 et v0.16.0. Un tag inconnu échoue de façon visible (`StopIteration`, code de sortie 1). Le motif ne trouve qu'une ligne dans chacun des 8 journaux lus (507, 508, 510 à 515), y compris le journal de release de 515 Ko. La sonde sépare donc Node 20 de Node 24 sur le seul workflow que la CI de PR n'exerce pas : c'est l'équivalent de mutation de cette revue. - **`docs/architecture.md`** : la description « un seul job `build-and-release` en conteneur `ubuntu:22.04`, Linux puis Windows par `cargo-xwin` » correspond à `release.yml:9-63`. La phrase sur les jetons est exacte : `GITHUB_TOKEN` et `PACKAGE_TOKEN` servent aux étapes suivantes (`release.yml:150` et `:221`), dans le même conteneur, en root. - Les commits sont conventionnels (`ci:`), avec `Resolves #376` dans le corps et sur `71a4e1e`. La timeline de #376 porte un seul `pull_ref` en `closes`, celui de cette PR ; #415 à #417 la citent sans la fermer. Aucun secret ni aucune donnée personnelle dans les lignes ajoutées. ### Réponses aux points « à relire en priorité » 1. Le commentaire `concurrency` ne prête pas au miroir GitHub la lecture de `.forgejo/workflows/`. La formulation de D2 est corrigée à bon droit. 2. **Garder la phrase sur `rustup`.** `release.yml:29` est le même `curl … | sh` en root, et `npx tauri build` lance cargo avec la clé de signature dans l'environnement, donc aussi les scripts de build de chaque crate. Sans cette phrase, NodeSource passerait pour le seul installeur à qui le job fait confiance. 3. La correction « Deux jobs » → un seul job est exacte (voir plus haut). ### Suggestions (non bloquantes) 1. **`STATE.md:79`** : la puce « Backlog ouvert » garde « **#376** (`status:triage` : Node 20 … encore installé par `check-frontend.yml` et `audit.yml` …) », que la nouvelle puce du même fichier contredit dès le merge. La mention est toujours là à la tête de la pile (`e8306aa`, ligne 80). Le journal de décisions du run la laisse au sync post-merge : la vérifier à ce moment-là, ou la retirer ici. 2. **`src/services/reportService.test.ts:722`** dit « CI runs Node 20 → no node:sqlite », ce qui devient faux au merge, puisque Node 24 a `node:sqlite`. Le changement revient à #392, qui prévoit le harnais `node:sqlite` et dépend de #376 : corriger le commentaire ici, ou le signaler sur #392. 3. **`.claude/skills/release/SKILL.md:48`**, « le paramètre `limit` y est ignoré » : ce n'est vrai que sans `page`. Mesuré ce jour : sans paramètre comme avec `?limit=5`, 611 lignes ; `?limit=5&page=2` en rend 5 et `?page=2` en rend 30. La commande ne passe ni l'un ni l'autre, elle est donc correcte, mais la parenthèse gagnerait à dire « sans `page`, la route rend toute la liste ». La même nuance vaut pour le message de `f19b027` et pour l'exemple `?limit=5` de `forgejo-ops.md` (autre dépôt). 4. **`audit.yml:30-31`** renvoie au commentaire de `check-rust.yml`, qui ne couvre que `push` et `pull_request`. Or `audit.yml` ne tourne que sur `schedule` et `workflow_dispatch`, que `forgejo-ops.md` ne mesure pas. Une demi-ligne dans le renvoi le dirait. Facultatif. ### Reste à prouver au prochain tag Il faudra lire `node --version` en `v24.x` dans le journal du run de release et obtenir `verify-release.sh` vert. L'étape 10 (cycle réel de mise à jour) s'applique aussi, puisque le diff touche `release.yml`. Tout cela est déjà consigné dans `STATE.md` et à l'étape 9 du skill. ### Actions faites - La suite n'a pas été rejouée en local : le changement ne touche que la CI, et la CI de la tête est verte dans les journaux (runs 514 et 515). Ce qui a tourné : la commande de l'étape 9 sur trois tags et un tag inconnu, le décompte du motif dans 8 journaux, la comparaison YAML entre `main` et la tête, `bash -n` sur les trois scripts, et la mesure de la pagination de `/actions/tasks`. - Aucun fichier du dépôt modifié. Les fichiers temporaires `/tmp/pr414-*` (journaux et script extrait) sont supprimés. - Label de #376 : `status:review` → `status:approved`, posé juste après ce commentaire.

maximus referenced this pull request 2026-10-11 23:02:22 +00:00

fix: give rpm installs their own key in latest.json #416

maximus referenced this pull request from a commit 2026-10-12 19:07:27 +00:00

docs: fix three comments after review of #414

maximus referenced this pull request 2026-10-12 19:08:09 +00:00

fix(release): apply the review follow-ups of the release-deps stack, drop the linux-x86_64 key #418

maximus referenced this pull request 2026-10-12 19:29:52 +00:00

fix(release): apply the review follow-ups of the release-deps stack, drop the linux-x86_64 key #418

maximus merged commit f19b027c5d into main 2026-10-12 19:32:20 +00:00

maximus referenced this pull request 2026-10-12 19:34:25 +00:00

Suivis de la revue de #418 : latest.json vide accepté sous jq 1.6, appel du filtre non testé, paths-ignore de check-frontend #419

maximus referenced this pull request from a commit 2026-10-12 19:36:15 +00:00

state: sync after the release-deps milestone (#376, #345, #320, #358)

maximus referenced this pull request 2026-10-12 19:36:25 +00:00

state: sync after the release-deps milestone #420

maximus referenced this pull request 2026-10-18 12:22:26 +00:00

docs(review): REVIEW.md, calibrated risk levels and review rules per zone (#456) #460

maximus referenced this pull request 2026-10-18 12:23:01 +00:00

Ajouter REVIEW.md : niveaux de risque calibrés et règles de revue par zone #456

maximus referenced this pull request 2026-10-18 12:43:22 +00:00

docs(review): REVIEW.md, calibrated risk levels and review rules per zone (#456) #460

maximus referenced this pull request 2026-10-18 18:19:23 +00:00

REVIEW.md : principes à la place des listes, conditions du script de calibration (suivis de la seconde revue de #460) #462

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

autopilot:pending-human

PR produced by /autopilot — awaits human review/merge

  

source:analyste

Créée par le Super-Analyste

  

source:defenseur

Créée par l Escouade Défenseur

  

source:human

Créée par un humain

  

source:medic

Créée par le Medic (auto-détection)

  

status:approved

PR approuvée, prête à merger

  

status:blocked

Bloquée (question, dépendance, clarification)

  

status:in-progress

Un agent (Medic/Dev) travaille dessus

  

status:needs-clarification

Issue blocked by ambiguity — Max needs to clarify before re-running autopilot

  

status:needs-fix

Reviewer demande des corrections

  

status:ready

Analysée et documentée, prête à prendre

  

status:review

PR créée, en attente du Reviewer

  

status:triage

Nouvelle issue, pas encore analysée

  

type:bug

Correction de bug → Medic

  

type:feature

Nouvelle fonctionnalité → Dev

  

type:infra

Config, CI/CD, déploiement → Dev

  

type:refactor

Refactoring / amélioration technique → Dev

  

type:schema

Modèle de données / migrations → Dev

  

type:security

Issue de sécurité → Medic ou Dev

No labels

autopilot:pending-human

source:analyste

source:defenseur

source:human

source:medic

status:approved

status:blocked

status:in-progress

status:needs-clarification

status:needs-fix

status:ready

status:review

status:triage

type:bug

type:feature

type:infra

type:refactor

type:schema

type:security

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

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: maximus/Simpl-Resultat#414

No description provided.