maximus/Simpl-Resultat
1
0
Fork 0
Code Issues 19 Pull requests 8 Projects Releases 34 Packages Wiki Activity Actions

ci: passer check-frontend, audit et release de Node 20 (fin de vie) à Node 24 ; réécrire le commentaire concurrency de check-rust #376

New issue
Closed
opened 2026-10-03 22:12:35 +00:00 by maximus · 1 comment
maximus commented 2026-10-03 22:12:35 +00:00
Owner
Copy link

Planification du 2026-10-10 (/plan-run, milestone planned-2026-10-10-release-deps) : les sections ci-dessous, à partir de « Dépendances », priment sur le texte d'analyse en cas d'écart.

Analyse /analyze du 2026-10-10, lue sur main 87920ec. Corps d'origine archivé en commentaire : release.yml y manquait.

Contexte

Node 20 est en fin de vie depuis le 2026-04-30. Trois workflows l'installent encore par deb.nodesource.com/setup_20.x :

  • .forgejo/workflows/check-frontend.yml:41-47
  • .forgejo/workflows/audit.yml:42-52
  • .forgejo/workflows/release.yml:19-26 (absent du corps d'origine)

check-rust.yml:92 est déjà en setup_24.x depuis #375 ; actions/checkout@v4 (déclaré node20) y tourne avec le node du conteneur.

Lien avec #392 : #392 (D3) prévoyait de passer check-frontend en Node 22 pour node:sqlite. node:sqlite existe aussi en Node 24 : #392 s'aligne sur Node 24 et n'a plus d'étape CI à elle (commentaire posé sur #392). Node 24 embarque npm 11, ce qui fait aussi disparaître le plantage de l'arborist de npm 10 sur vitest 4.1.x noté en #358 (le lock reste lu par npm ci).

concurrency : le commentaire de check-rust.yml:55-57 dit « Cancel obsolete runs (e.g. on force-push) so only the latest commit runs ». la-compagnie-maximus/docs/forgejo-ops.md (section « Le schéma du workflow est validé par le runner », mesuré sur Forgejo 8.0.3) dit que la clé passe la validation mais que son effet n'a pas été isolé, l'annulation du run précédent d'un push existant aussi sans elle, et qu'aucun run pull_request n'est annulé par un run suivant.

Décisions (Max, 2026-10-10)

  • D1 — Node 24 partout : les trois workflows passent à setup_24.x.
  • D2 — Clés concurrency gardées, commentaire réécrit : elles sont inoffensives et servent au miroir GitHub dormant et à une future version de Forgejo. Le commentaire de check-rust.yml (et ceux, s'il y en a, de check-frontend.yml:28 et audit.yml) décrit ce que la doc d'ops a mesuré, avec un renvoi vers elle.

Travail à faire

  • check-frontend.yml, audit.yml, release.yml : setup_20.x → setup_24.x, nom d'étape « Install Node.js 24 », node --version gardé dans le log.
  • Réécrire le commentaire concurrency de check-rust.yml:55-57 d'après forgejo-ops.md ; harmoniser check-frontend.yml et audit.yml.
  • CLAUDE.md (section CI/CD) et docs/architecture.md (section CI/CD) : Node 24 si la version y est citée.
  • Commenter sur #392 que l'étape CI Node 22 est remplacée par cette issue (fait à l'analyse).
  • Pas d'entrée CHANGELOG (CI seulement).

Fichiers concernés

  • .forgejo/workflows/check-frontend.yml, .forgejo/workflows/audit.yml, .forgejo/workflows/release.yml, .forgejo/workflows/check-rust.yml (commentaire)
  • CLAUDE.md, docs/architecture.md (si la version de Node y figure)

Surface de test

Infra CI, pas de test unitaire. Preuves lues dans les journaux (route web /{owner}/{repo}/actions/runs/{n}/jobs/0/logs) :

  • check-frontend de la PR : node --version = v24.x, npm ci, build et tests verts.
  • audit : workflow_dispatch sur la branche, node --version = v24.x, audit vert.
  • release.yml : non prouvable avant le prochain tag. À confirmer à la prochaine release (étape node --version du run et verify-release.sh vert) ; le noter dans la PR et dans le pré-vol de /release.

Critères d'acceptation

  • Plus aucun setup_20.x dans .forgejo/workflows/.
  • check-frontend et audit verts sous Node 24, lu dans les journaux.
  • Le commentaire concurrency ne contredit plus forgejo-ops.md.
  • La vérification de release.yml est notée pour la prochaine release.

Complexité estimée

Simple.

Liens

#375 (Node 24 dans check-rust), #392 (D3, node:sqlite), #358 (npm 10/11), la-compagnie-maximus/docs/forgejo-ops.md.

Dépendances

Depends on

(aucune)

Fichiers concernés (complet)

  • .forgejo/workflows/check-frontend.yml, .forgejo/workflows/audit.yml, .forgejo/workflows/release.yml (Node 24), .forgejo/workflows/check-rust.yml (commentaire concurrency)
  • CLAUDE.md (section CI/CD), docs/architecture.md (section CI/CD) si Node y est cité ; risque NodeSource nommé (voir décisions)

Critères d'acceptation (planification)

  • grep -rn setup_20 .forgejo/workflows/ ne renvoie rien.
  • Journal check-frontend de la PR : node --version affiche v24.x, npm ci, build et tests verts.
  • audit sous Node 24 prouvé par un workflow_dispatch sur la branche (voir décisions pour le repli).
  • Commentaire concurrency conforme à la-compagnie-maximus/docs/forgejo-ops.md (aucun run pull_request annulé par un suivant ; effet de la clé non isolé sur Forgejo 8.0.3).
  • La PR liste ce qui ne se prouve qu'au prochain tag (release.yml sous Node 24).

Review caveats

  • 🟢 SECURITE : curl | bash NodeSource s'exécute en root dans le conteneur de release.yml qui reçoit ensuite TAURI_SIGNING_PRIVATE_KEY. Gardé (décision), mais nommé dans le commentaire du workflow et dans docs/architecture.md.
  • 🟢 TECHNIQUE : release.yml n'est exercé qu'au prochain tag. Ajouter à .claude/skills/release/SKILL.md (pré-vol ou vérification) : lire node --version dans le journal du run de release.

Décisions prises en planification

  • Node 24 dans les trois workflows (Max, 2026-10-10).
  • Clés concurrency gardées, commentaire réécrit (Max, 2026-10-10).
  • NodeSource gardé dans release.yml, risque documenté ; pas de tarball épinglé (Max, 2026-10-10).
  • Preuve audit : déclencher par l'API POST /repos/maximus/simpl-resultat/actions/workflows/audit.yml/dispatches avec {"ref":"<branche>"}. Si l'API ne répond pas 2xx, poser autopilot:pending-human sur la PR avec la consigne « lancer Security audit sur la branche depuis l'UI Actions et lire node --version », sans bloquer la suite de la pile.
  • Pas d'entrée CHANGELOG.

Spec source

spec-plan-release-deps.md (local, ignoré par git)

> **Planification du 2026-10-10** (`/plan-run`, milestone `planned-2026-10-10-release-deps`) : les sections ci-dessous, à partir de « Dépendances », **priment** sur le texte d'analyse en cas d'écart. > Analyse `/analyze` du 2026-10-10, lue sur `main` `87920ec`. Corps d'origine archivé en commentaire : `release.yml` y manquait. ## Contexte Node 20 est en fin de vie depuis le 2026-04-30. Trois workflows l'installent encore par `deb.nodesource.com/setup_20.x` : - `.forgejo/workflows/check-frontend.yml:41-47` - `.forgejo/workflows/audit.yml:42-52` - `.forgejo/workflows/release.yml:19-26` (absent du corps d'origine) `check-rust.yml:92` est déjà en `setup_24.x` depuis #375 ; `actions/checkout@v4` (déclaré `node20`) y tourne avec le `node` du conteneur. **Lien avec #392** : #392 (D3) prévoyait de passer `check-frontend` en Node 22 pour `node:sqlite`. `node:sqlite` existe aussi en Node 24 : #392 s'aligne sur Node 24 et n'a plus d'étape CI à elle (commentaire posé sur #392). Node 24 embarque npm 11, ce qui fait aussi disparaître le plantage de l'arborist de npm 10 sur vitest 4.1.x noté en #358 (le lock reste lu par `npm ci`). **`concurrency`** : le commentaire de `check-rust.yml:55-57` dit « Cancel obsolete runs (e.g. on force-push) so only the latest commit runs ». `la-compagnie-maximus/docs/forgejo-ops.md` (section « Le schéma du workflow est validé par le runner », mesuré sur Forgejo 8.0.3) dit que la clé passe la validation mais que son effet n'a pas été isolé, l'annulation du run précédent d'un `push` existant aussi sans elle, et qu'aucun run `pull_request` n'est annulé par un run suivant. ## Décisions (Max, 2026-10-10) - **D1 — Node 24 partout** : les trois workflows passent à `setup_24.x`. - **D2 — Clés `concurrency` gardées, commentaire réécrit** : elles sont inoffensives et servent au miroir GitHub dormant et à une future version de Forgejo. Le commentaire de `check-rust.yml` (et ceux, s'il y en a, de `check-frontend.yml:28` et `audit.yml`) décrit ce que la doc d'ops a mesuré, avec un renvoi vers elle. ## Travail à faire - [ ] `check-frontend.yml`, `audit.yml`, `release.yml` : `setup_20.x` → `setup_24.x`, nom d'étape « Install Node.js 24 », `node --version` gardé dans le log. - [ ] Réécrire le commentaire `concurrency` de `check-rust.yml:55-57` d'après `forgejo-ops.md` ; harmoniser `check-frontend.yml` et `audit.yml`. - [ ] `CLAUDE.md` (section CI/CD) et `docs/architecture.md` (section CI/CD) : Node 24 si la version y est citée. - [ ] Commenter sur #392 que l'étape CI Node 22 est remplacée par cette issue (fait à l'analyse). - Pas d'entrée CHANGELOG (CI seulement). ## Fichiers concernés - `.forgejo/workflows/check-frontend.yml`, `.forgejo/workflows/audit.yml`, `.forgejo/workflows/release.yml`, `.forgejo/workflows/check-rust.yml` (commentaire) - `CLAUDE.md`, `docs/architecture.md` (si la version de Node y figure) ## Surface de test Infra CI, pas de test unitaire. Preuves lues dans les journaux (route web `/{owner}/{repo}/actions/runs/{n}/jobs/0/logs`) : - `check-frontend` de la PR : `node --version` = v24.x, `npm ci`, build et tests verts. - `audit` : `workflow_dispatch` sur la branche, `node --version` = v24.x, audit vert. - `release.yml` : non prouvable avant le prochain tag. **À confirmer** à la prochaine release (étape `node --version` du run et `verify-release.sh` vert) ; le noter dans la PR et dans le pré-vol de `/release`. ## Critères d'acceptation - [ ] Plus aucun `setup_20.x` dans `.forgejo/workflows/`. - [ ] `check-frontend` et `audit` verts sous Node 24, lu dans les journaux. - [ ] Le commentaire `concurrency` ne contredit plus `forgejo-ops.md`. - [ ] La vérification de `release.yml` est notée pour la prochaine release. ## Complexité estimée Simple. ## Liens #375 (Node 24 dans `check-rust`), #392 (D3, `node:sqlite`), #358 (npm 10/11), `la-compagnie-maximus/docs/forgejo-ops.md`. --- ## Dépendances ## Depends on (aucune) ## Fichiers concernés (complet) - `.forgejo/workflows/check-frontend.yml`, `.forgejo/workflows/audit.yml`, `.forgejo/workflows/release.yml` (Node 24), `.forgejo/workflows/check-rust.yml` (commentaire `concurrency`) - `CLAUDE.md` (section CI/CD), `docs/architecture.md` (section CI/CD) si Node y est cité ; risque NodeSource nommé (voir décisions) ## Critères d'acceptation (planification) - [ ] `grep -rn setup_20 .forgejo/workflows/` ne renvoie rien. - [ ] Journal `check-frontend` de la PR : `node --version` affiche v24.x, `npm ci`, build et tests verts. - [ ] `audit` sous Node 24 prouvé par un `workflow_dispatch` sur la branche (voir décisions pour le repli). - [ ] Commentaire `concurrency` conforme à `la-compagnie-maximus/docs/forgejo-ops.md` (aucun run `pull_request` annulé par un suivant ; effet de la clé non isolé sur Forgejo 8.0.3). - [ ] La PR liste ce qui ne se prouve qu'au prochain tag (`release.yml` sous Node 24). ## Review caveats - 🟢 SECURITE : `curl | bash` NodeSource s'exécute en root dans le conteneur de `release.yml` qui reçoit ensuite `TAURI_SIGNING_PRIVATE_KEY`. Gardé (décision), mais nommé dans le commentaire du workflow et dans `docs/architecture.md`. - 🟢 TECHNIQUE : `release.yml` n'est exercé qu'au prochain tag. Ajouter à `.claude/skills/release/SKILL.md` (pré-vol ou vérification) : lire `node --version` dans le journal du run de release. ## Décisions prises en planification - Node 24 dans les trois workflows (Max, 2026-10-10). - Clés `concurrency` gardées, commentaire réécrit (Max, 2026-10-10). - NodeSource gardé dans `release.yml`, risque documenté ; pas de tarball épinglé (Max, 2026-10-10). - Preuve `audit` : déclencher par l'API `POST /repos/maximus/simpl-resultat/actions/workflows/audit.yml/dispatches` avec `{"ref":"<branche>"}`. Si l'API ne répond pas 2xx, poser `autopilot:pending-human` sur la PR avec la consigne « lancer Security audit sur la branche depuis l'UI Actions et lire `node --version` », sans bloquer la suite de la pile. - Pas d'entrée CHANGELOG. ## Spec source `spec-plan-release-deps.md` (local, ignoré par git)
maximus added the
status:triage
type:infra
source:human
 labels 2026-10-03 22:12:35 +00:00
maximus commented 2026-10-10 23:10:48 +00:00
Author
Owner
Copy link

Archive avant réécriture par /analyze (2026-10-10, lu sur main 87920ec). Le corps est réécrit avec les décisions de Max du jour ; le texte d'origine est conservé ci-dessous.

Corps d'origine

Deux constats hors du périmètre de #375, relevés par sa revue (commentaire 18946) et vérifiés dans les fichiers le 2026-10-03.

1. Node 20 en fin de vie

check-frontend.yml et audit.yml installent Node.js par deb.nodesource.com/setup_20.x. Node 20 est en fin de vie depuis le 2026-04-30. check-rust.yml est passé à Node 24 dans #375, parce que rust-cache déclare node24 ; actions/checkout@v4, déclaré node20, y tourne sans souci avec le node du conteneur.

  • Passer les deux workflows à setup_24.x.
  • Lire dans le journal de la PR que check-frontend (npm ci, build, tests) passe sous Node 24.

2. Commentaire concurrency de check-rust.yml

Le commentaire au-dessus de concurrency: dit « Cancel obsolete runs (e.g. on force-push) so only the latest commit runs ». la-compagnie-maximus/docs/forgejo-ops.md, mesuré le 2026-10-02 sur Forgejo 8.0.3, dit l'inverse pour les PR : aucun run pull_request n'est annulé par un run suivant, et l'annulation des runs push existe sans la clé.

  • Réécrire ce commentaire d'après la mesure de la doc d'ops, ou retirer les clés concurrency des trois workflows si elles sont inertes : à trancher.

Pas d'entrée CHANGELOG : configuration CI seulement.

Archive avant réécriture par `/analyze` (2026-10-10, lu sur `main` `87920ec`). Le corps est réécrit avec les décisions de Max du jour ; le texte d'origine est conservé ci-dessous. <details><summary>Corps d'origine</summary> Deux constats hors du périmètre de #375, relevés par sa revue (commentaire 18946) et vérifiés dans les fichiers le 2026-10-03. ## 1. Node 20 en fin de vie `check-frontend.yml` et `audit.yml` installent Node.js par `deb.nodesource.com/setup_20.x`. Node 20 est en fin de vie depuis le 2026-04-30. `check-rust.yml` est passé à Node 24 dans #375, parce que rust-cache déclare `node24` ; `actions/checkout@v4`, déclaré `node20`, y tourne sans souci avec le `node` du conteneur. - [ ] Passer les deux workflows à `setup_24.x`. - [ ] Lire dans le journal de la PR que `check-frontend` (`npm ci`, build, tests) passe sous Node 24. ## 2. Commentaire `concurrency` de `check-rust.yml` Le commentaire au-dessus de `concurrency:` dit « Cancel obsolete runs (e.g. on force-push) so only the latest commit runs ». `la-compagnie-maximus/docs/forgejo-ops.md`, mesuré le 2026-10-02 sur Forgejo 8.0.3, dit l'inverse pour les PR : aucun run `pull_request` n'est annulé par un run suivant, et l'annulation des runs `push` existe sans la clé. - [ ] Réécrire ce commentaire d'après la mesure de la doc d'ops, ou retirer les clés `concurrency` des trois workflows si elles sont inertes : à trancher. Pas d'entrée CHANGELOG : configuration CI seulement. </details>
maximus changed title from ci: Node 20 en fin de vie dans check-frontend et audit ; commentaire concurrency de check-rust démenti par la doc d'ops to ci: passer check-frontend, audit et release de Node 20 (fin de vie) à Node 24 ; réécrire le commentaire concurrency de check-rust 2026-10-10 23:12:20 +00:00
maximus added
status:ready
 and removed
status:triage
 labels 2026-10-10 23:12:21 +00:00
maximus added this to the planned-2026-10-10-release-deps milestone 2026-10-10 23:22:28 +00:00
maximus added
status:in-progress
 and removed
status:ready
 labels 2026-10-10 23:33:47 +00:00
maximus added
status:review
 and removed
status:in-progress
 labels 2026-10-10 23:45:35 +00:00
maximus added
status:approved
 and removed
status:review
 labels 2026-10-11 22:32:06 +00:00
maximus removed the
status:approved
 label 2026-10-12 19:33:42 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
issue-446-review-followups
issue-384-onboarding-followups
issue-437-test-pins
issue-393-category-hierarchy
issue-429-category-combobox-portal
issue-372-systems-journal-first
issue-449-cargo-locked
issue-453-i18n-keys-guard
v0.17.2
v0.17.1
v0.17.0
v0.16.0
v0.15.0
v0.14.0
v0.13.0
v0.12.0
v0.11.0
v0.10.1
v0.10.0
v0.9.1
v0.9.0
v0.8.4
v0.8.3
v0.8.2
v0.8.1
v0.8.0
v0.7.4
v0.7.3
v0.7.2
v0.7.1
v0.7.0
v0.6.7
v0.6.6
v0.6.5
v0.6.4
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.2
v0.5.0
v0.4.2
v0.4.0
v0.3.11
v0.3.10
v0.3.9
v0.3.8
v0.3.7
v0.3.6
v0.3.5
v0.3.4
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.12
v0.2.11
v0.2.10
v0.2.9
v0.2.8
v0.2.7
v0.2.6
v0.2.5
v0.2.4
v0.2.3
v0.2.2
v0.2.1
v0.2.0
v0.1.2
v0.1.1
v0.1.0
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
planned-2026-10-10-release-deps
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
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#376
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?