maximus/Simpl-Resultat

Fork 0

CI : cargo check, cargo test et tauri build sans --locked — un Cargo.lock incohérent serait réécrit en silence avant les gardes #449

New issue

Open

opened 2026-10-16 23:12:57 +00:00 by maximus · 1 comment

maximus commented

2026-10-16 23:12:57 +00:00

Owner

Contexte

Suggestion non bloquante de la revue de la PR #448 (commentaire 23853) : la CI ne prouve pas elle-même que le lock audité est celui qu'on compile.

check-rust.yml lance cargo check --manifest-path src-tauri/Cargo.toml --all-targets (l. 130) et cargo test --manifest-path src-tauri/Cargo.toml --all-targets (l. 328), tous deux sans --locked. Si le Cargo.lock commité ne correspond plus à Cargo.toml (édition à la main, conflit mal résolu, dépendance ajoutée sans son lock), cargo le réécrit dans le checkout du job, sans erreur, puis compile ce graphe-là. Les deux gardes qui suivent (cargo tree --locked, lecture du lock par awk) et l'étape cargo audit lisent alors le lock réécrit, pas le commité. Le commentaire de la garde windows-sys l'admet (l. 215-217 : « the committed one unless cargo had to update it »), comme l'ADR 0023 (l. 76 : « il lit le lock tel que cargo check l'a laissé »).
release.yml construit les binaires livrés par npx tauri build --bundles deb,rpm (l. 56) et npx tauri build --runner cargo-xwin --target x86_64-pc-windows-msvc (l. 63), sans --locked non plus. L'étape 2 de /release édite Cargo.lock à la main (bloc simpl-result, « ne PAS regenerer avec cargo ») et le commit de release va sur main sans PR : seule la garde windows-sys est rejouée, aucun cargo metadata --locked.
audit.yml n'est pas concerné : il lit le lock commité (cargo-audit audit --file src-tauri/Cargo.lock), sans build.

Analyse (2026-10-16, `main` `d8037be`)

Prémisse vérifiée ligne à ligne. cargo metadata --manifest-path src-tauri/Cargo.toml --format-version 1 --locked est à exit 0 sur le lock actuel.
npx tauri build --help (@tauri-apps/cli 2.10.0, node_modules/@tauri-apps/cli/package.json) documente [ARGS]... : « Command line arguments passed to the runner. Use -- to explicitly mark the start of the arguments », et -r, --runner <RUNNER> : « Binary to use to build the application, defaults to cargo ». Le wrapper tauri.js transmet les arguments tels quels au binaire natif ; le relais par cargo-xwin vers cargo n'est pas vérifiable en lisant le code, il faut l'éprouver.
Les journaux des releases 451, 491 et 508 n'impriment jamais la ligne de commande cargo (seulement Running beforeBuildCommand, Updating crates.io index, Finished release profile). Un journal de build vert ne prouve donc pas que --locked est passé ; seule la preuve par un lock désaccordé qui fait échouer le build le prouve.
Le miroir .github/workflows/check.yml est déjà déphasé de 365 lignes (ancienne mise en page combinée, en-tête qui cite un .forgejo/workflows/check.yml disparu) et release.yml de 303 lignes. Dormant, aucune PR côté GitHub (CLAUDE.md l. 170).
Aucun test ne lit les drapeaux des workflows (scripts/build-latest-json.test.mjs ne couvre que latest.json). Le cache Swatinem/rust-cache@v2 (workspaces: "src-tauri -> target") hache le lock dans sa clé ; --locked ne change pas la clé.

Décision de Max (2026-10-16) : portée CI + skill /release. Le miroir .github/workflows/ reste tel quel.

Travail à faire

check-rust.yml : ajouter --locked à cargo check (l. 130) et à cargo test (l. 328). Réécrire le commentaire de la garde windows-sys (l. 215-217) : le lock lu est le commité, cargo check --locked ayant déjà refusé tout lock à réécrire. Même retouche à l'ADR 0023 (l. 76).
release.yml : npx tauri build --bundles deb,rpm -- --locked (l. 56) et npx tauri build --runner cargo-xwin --target x86_64-pc-windows-msvc -- --locked (l. 63).
Preuve locale, sans tag : sur un Cargo.toml modifié sans son lock (par exemple une borne de dépendance déplacée), cargo check --manifest-path src-tauri/Cargo.toml --all-targets --locked doit échouer avec le message de cargo sur un lock à mettre à jour malgré --locked, puis npx tauri build --bundles deb -- --locked sous Linux doit échouer de la même façon, ce qui prouve le relais des arguments à cargo. Le relais par cargo-xwin se prouve de même si cargo-xwin est installable localement ; sinon le noter « à confirmer au prochain tag ».
Preuve CI : sur une branche jetable portant le même lock désaccordé, check-rust doit rougir à l'étape cargo check ; citer le run. Puis vert sur le lock réel.
.claude/skills/release/SKILL.md, étape 2 : juste après l'édition de Cargo.lock et avant la garde windows-sys, lancer cargo metadata --manifest-path src-tauri/Cargo.toml --format-version 1 --locked > /dev/null et exiger exit 0 (commande déjà dans l'ADR 0023, l. 103-106). Ajouter la ligne au journal des changements du skill.
CLAUDE.md, section CI/CD : cargo check --locked et cargo test --locked dans la description de check-rust.yml, et une phrase sur release.yml (binaires bâtis sur le lock commité, jamais réécrit). Une ligne qui dit pourquoi le miroir .github n'est pas aligné.

Fichiers concernés

.forgejo/workflows/check-rust.yml : l. 130, 328, commentaire l. 215-217
.forgejo/workflows/release.yml : l. 56, 63
docs/adr/0023-windows-sys-pinning.md : l. 76
.claude/skills/release/SKILL.md : étape 2
CLAUDE.md : section CI/CD

Surface de test

Aucun test existant ne touche ces fichiers.
Preuves attendues à la place : rouge local (cargo check --locked, npx tauri build -- --locked), rouge CI sur branche jetable (run cité), vert CI sur le lock réel.

Critères d'acceptation

cargo check et cargo test de check-rust.yml passent --locked ; commentaire l. 215-217 et ADR 0023 l. 76 réécrits.
Les deux builds de release.yml portent -- --locked.
Preuve locale : cargo check --locked et npx tauri build --bundles deb -- --locked échouent sur un lock désaccordé, sortie citée dans la PR (message de cargo). Relais cargo-xwin prouvé ou marqué « à confirmer au prochain tag ».
Preuve CI : un lock désaccordé fait rougir check-rust, run cité.
check-rust vert avec --locked sur le lock actuel.
/release étape 2 lance cargo metadata --locked après l'édition du lock.
CLAUDE.md à jour ; miroir .github/workflows/ intact.
Le cargo update d'une PR et l'édition à la main de /release restent possibles : --locked n'interdit que la réécriture implicite pendant la CI et le build.

Vérification post-merge (au prochain tag)

Run de release vert avec -- --locked sur les deux cibles ; comme le journal n'imprime pas la ligne cargo, le vert plus la preuve locale du point 3 constituent la preuve.

Complexité

Simple.

Liens

Revue de la PR #448 (commentaire 23853), issue #447
ADR 0023 (garde windows-sys), ADR 0018 et .cargo/audit.toml
Skill /release, étape 2 (édition du lock à la main)

Plan d'exécution — milestone lot-v018 (planifié le 2026-10-16)

Les sections ci-dessous viennent de la séance /plan-run du 2026-10-16 (revue /review-spec Sécurité, Architecture, Technique comprise). En cas de conflit avec le corps au-dessus, elles priment.

Consignes communes

Préflight : #369, #419 et #421 sont fermées et le tag v0.17.2 existe (git ls-remote --tags origin v0.17.2). Sinon, arrêt sans rien écrire.
Les numéros de ligne du corps ont été lus sur main 065f580 ; #369, #419 et #421 les ont déplacés depuis. Repérer chaque site par son contenu (symbole, chaîne), jamais par son numéro.
Toute clé i18n ajoutée l'est en FR et en EN (garde de #453, en tête de pile).
Les vérifications manuelles (app lancée) vont dans le corps de la PR et le DAILY-REPORT, pas dans STATE.md : le report dans STATE.md se fait au /merge-stack.

Depends on

#453

Note : dépendance d'ordre de la pile (fichiers partagés), pas de dépendance de code.

Décisions prises en planification

Preuve CI rouge (Max) : branche jetable throwaway-449-lock-mismatch partant de la branche de l'issue, portant un src-tauri/Cargo.toml désaccordé de son lock. check-rust y est lancé par l'API (POST /repos/maximus/simpl-resultat/actions/workflows/check-rust.yml/dispatches avec {"ref": "throwaway-449-lock-mismatch"}, 204 attendu), sans ouvrir de PR. Le run rouge est cité dans la PR, puis la branche est supprimée (git push origin --delete throwaway-449-lock-mismatch). Sur la branche de l'issue, git diff main -- src-tauri/Cargo.toml doit rester vide. Un run en échec ne sauvegarde pas de cache (Swatinem/rust-cache, cache-on-failure à false par défaut) : le cache partagé n'est pas touché.
cargo-xwin (Max) : épingler cargo install --locked cargo-xwin --version <X.Y.Z> dans release.yml, avec la dernière version stable publiée sur crates.io au moment du maillon, et ajouter une ligne cargo-xwin --version au journal. Raison : l'outil tourne dans l'étape qui porte TAURI_SIGNING_PRIVATE_KEY. Le relais de -- --locked par cargo-xwin n'est pas prouvé en local (SDK MSVC de plusieurs Go) : la PR le marque « à confirmer au prochain tag », et la vérification rejoint la liste de la release (le build Windows rougirait avant toute publication, l'updater ne bouge pas).
CLAUDE.md, section CI/CD : mentionner aussi l'épinglage de cargo-xwin.

Review caveats

(Technique, corrigé) check-rust ne tourne pas sur un simple push de branche : d'où le workflow_dispatch ci-dessus.
(Sécurité, retenu) cargo-xwin non épinglé : traité par l'épinglage.

Spec source

spec-plan-lot-v018.md

Note du 2026-10-18 : `REVIEW.md` est mergé

Reprise du commentaire 24475, écrit avant le merge de REVIEW.md (PR #460, main 24da72b).

La section « Commandes de vérification » de REVIEW.md décrit la CI sans --locked : la ligne check-rust.yml du tableau, les lignes cargo check et cargo test du bloc des commandes locales, et la phrase « cargo check et cargo test tournent sans --locked dans la CI ; #449 l'ajoute, et sa PR met ce tableau à jour. » La PR de cette issue ajoute --locked aux commandes du tableau et du bloc, puis retire cette phrase. Repérer ces passages par leur texte, pas par un numéro de ligne.
Selon REVIEW.md, cette PR est de niveau haut : elle modifie des étapes de verdict de check-rust.yml et touche release.yml.
REVIEW.md s'ajoute aux fichiers concernés.

## Contexte Suggestion non bloquante de la revue de la PR #448 (commentaire 23853) : la CI ne prouve pas elle-même que le lock audité est celui qu'on compile. - `check-rust.yml` lance `cargo check --manifest-path src-tauri/Cargo.toml --all-targets` (l. 130) et `cargo test --manifest-path src-tauri/Cargo.toml --all-targets` (l. 328), tous deux **sans `--locked`**. Si le `Cargo.lock` commité ne correspond plus à `Cargo.toml` (édition à la main, conflit mal résolu, dépendance ajoutée sans son lock), cargo le réécrit dans le checkout du job, sans erreur, puis compile ce graphe-là. Les deux gardes qui suivent (`cargo tree --locked`, lecture du lock par `awk`) et l'étape `cargo audit` lisent alors le lock réécrit, pas le commité. Le commentaire de la garde `windows-sys` l'admet (l. 215-217 : « the committed one unless cargo had to update it »), comme l'ADR 0023 (l. 76 : « il lit le lock tel que `cargo check` l'a laissé »). - `release.yml` construit les binaires livrés par `npx tauri build --bundles deb,rpm` (l. 56) et `npx tauri build --runner cargo-xwin --target x86_64-pc-windows-msvc` (l. 63), sans `--locked` non plus. L'étape 2 de `/release` édite `Cargo.lock` à la main (bloc `simpl-result`, « ne PAS regenerer avec cargo ») et le commit de release va sur `main` sans PR : seule la garde `windows-sys` est rejouée, aucun `cargo metadata --locked`. - `audit.yml` n'est pas concerné : il lit le lock commité (`cargo-audit audit --file src-tauri/Cargo.lock`), sans build. ## Analyse (2026-10-16, `main` `d8037be`) - Prémisse vérifiée ligne à ligne. `cargo metadata --manifest-path src-tauri/Cargo.toml --format-version 1 --locked` est à exit 0 sur le lock actuel. - `npx tauri build --help` (`@tauri-apps/cli` 2.10.0, `node_modules/@tauri-apps/cli/package.json`) documente `[ARGS]...` : « Command line arguments passed to the runner. Use `--` to explicitly mark the start of the arguments », et `-r, --runner <RUNNER>` : « Binary to use to build the application, defaults to `cargo` ». Le wrapper `tauri.js` transmet les arguments tels quels au binaire natif ; le relais par `cargo-xwin` vers cargo n'est pas vérifiable en lisant le code, il faut l'éprouver. - Les journaux des releases 451, 491 et 508 n'impriment jamais la ligne de commande cargo (seulement `Running beforeBuildCommand`, `Updating crates.io index`, `Finished release profile`). Un journal de build vert ne prouve donc pas que `--locked` est passé ; seule la preuve par un lock désaccordé qui fait échouer le build le prouve. - Le miroir `.github/workflows/check.yml` est déjà déphasé de 365 lignes (ancienne mise en page combinée, en-tête qui cite un `.forgejo/workflows/check.yml` disparu) et `release.yml` de 303 lignes. Dormant, aucune PR côté GitHub (`CLAUDE.md` l. 170). - Aucun test ne lit les drapeaux des workflows (`scripts/build-latest-json.test.mjs` ne couvre que `latest.json`). Le cache `Swatinem/rust-cache@v2` (`workspaces: "src-tauri -> target"`) hache le lock dans sa clé ; `--locked` ne change pas la clé. **Décision de Max (2026-10-16)** : portée CI + skill `/release`. Le miroir `.github/workflows/` reste tel quel. ## Travail à faire 1. `check-rust.yml` : ajouter `--locked` à `cargo check` (l. 130) et à `cargo test` (l. 328). Réécrire le commentaire de la garde `windows-sys` (l. 215-217) : le lock lu est le commité, `cargo check --locked` ayant déjà refusé tout lock à réécrire. Même retouche à l'ADR 0023 (l. 76). 2. `release.yml` : `npx tauri build --bundles deb,rpm -- --locked` (l. 56) et `npx tauri build --runner cargo-xwin --target x86_64-pc-windows-msvc -- --locked` (l. 63). 3. Preuve locale, sans tag : sur un `Cargo.toml` modifié sans son lock (par exemple une borne de dépendance déplacée), `cargo check --manifest-path src-tauri/Cargo.toml --all-targets --locked` doit échouer avec le message de cargo sur un lock à mettre à jour malgré `--locked`, puis `npx tauri build --bundles deb -- --locked` sous Linux doit échouer de la même façon, ce qui prouve le relais des arguments à cargo. Le relais par `cargo-xwin` se prouve de même si `cargo-xwin` est installable localement ; sinon le noter « à confirmer au prochain tag ». 4. Preuve CI : sur une branche jetable portant le même lock désaccordé, `check-rust` doit rougir à l'étape `cargo check` ; citer le run. Puis vert sur le lock réel. 5. `.claude/skills/release/SKILL.md`, étape 2 : juste après l'édition de `Cargo.lock` et avant la garde `windows-sys`, lancer `cargo metadata --manifest-path src-tauri/Cargo.toml --format-version 1 --locked > /dev/null` et exiger exit 0 (commande déjà dans l'ADR 0023, l. 103-106). Ajouter la ligne au journal des changements du skill. 6. `CLAUDE.md`, section CI/CD : `cargo check --locked` et `cargo test --locked` dans la description de `check-rust.yml`, et une phrase sur `release.yml` (binaires bâtis sur le lock commité, jamais réécrit). Une ligne qui dit pourquoi le miroir `.github` n'est pas aligné. ## Fichiers concernés - `.forgejo/workflows/check-rust.yml` : l. 130, 328, commentaire l. 215-217 - `.forgejo/workflows/release.yml` : l. 56, 63 - `docs/adr/0023-windows-sys-pinning.md` : l. 76 - `.claude/skills/release/SKILL.md` : étape 2 - `CLAUDE.md` : section CI/CD ## Surface de test - Aucun test existant ne touche ces fichiers. - Preuves attendues à la place : rouge local (`cargo check --locked`, `npx tauri build -- --locked`), rouge CI sur branche jetable (run cité), vert CI sur le lock réel. ## Critères d'acceptation - [ ] `cargo check` et `cargo test` de `check-rust.yml` passent `--locked` ; commentaire l. 215-217 et ADR 0023 l. 76 réécrits. - [ ] Les deux builds de `release.yml` portent `-- --locked`. - [ ] Preuve locale : `cargo check --locked` et `npx tauri build --bundles deb -- --locked` échouent sur un lock désaccordé, sortie citée dans la PR (message de cargo). Relais `cargo-xwin` prouvé ou marqué « à confirmer au prochain tag ». - [ ] Preuve CI : un lock désaccordé fait rougir `check-rust`, run cité. - [ ] `check-rust` vert avec `--locked` sur le lock actuel. - [ ] `/release` étape 2 lance `cargo metadata --locked` après l'édition du lock. - [ ] `CLAUDE.md` à jour ; miroir `.github/workflows/` intact. - [ ] Le `cargo update` d'une PR et l'édition à la main de `/release` restent possibles : `--locked` n'interdit que la réécriture implicite pendant la CI et le build. ## Vérification post-merge (au prochain tag) - Run de release vert avec `-- --locked` sur les deux cibles ; comme le journal n'imprime pas la ligne cargo, le vert plus la preuve locale du point 3 constituent la preuve. ## Complexité Simple. ## Liens - Revue de la PR #448 (commentaire 23853), issue #447 - ADR 0023 (garde `windows-sys`), ADR 0018 et `.cargo/audit.toml` - Skill `/release`, étape 2 (édition du lock à la main) --- # Plan d'exécution — milestone lot-v018 (planifié le 2026-10-16) Les sections ci-dessous viennent de la séance `/plan-run` du 2026-10-16 (revue `/review-spec` Sécurité, Architecture, Technique comprise). **En cas de conflit avec le corps au-dessus, elles priment.** ## Consignes communes - Préflight : #369, #419 et #421 sont fermées et le tag `v0.17.2` existe (`git ls-remote --tags origin v0.17.2`). Sinon, arrêt sans rien écrire. - Les numéros de ligne du corps ont été lus sur `main` `065f580` ; #369, #419 et #421 les ont déplacés depuis. Repérer chaque site par son contenu (symbole, chaîne), jamais par son numéro. - Toute clé i18n ajoutée l'est en FR et en EN (garde de #453, en tête de pile). - Les vérifications manuelles (app lancée) vont dans le corps de la PR et le DAILY-REPORT, pas dans `STATE.md` : le report dans `STATE.md` se fait au `/merge-stack`. ## Depends on - #453 Note : dépendance d'ordre de la pile (fichiers partagés), pas de dépendance de code. ## Décisions prises en planification - **Preuve CI rouge** (Max) : branche jetable `throwaway-449-lock-mismatch` partant de la branche de l'issue, portant un `src-tauri/Cargo.toml` désaccordé de son lock. `check-rust` y est lancé par l'API (`POST /repos/maximus/simpl-resultat/actions/workflows/check-rust.yml/dispatches` avec `{"ref": "throwaway-449-lock-mismatch"}`, 204 attendu), sans ouvrir de PR. Le run rouge est cité dans la PR, puis la branche est supprimée (`git push origin --delete throwaway-449-lock-mismatch`). Sur la branche de l'issue, `git diff main -- src-tauri/Cargo.toml` doit rester vide. Un run en échec ne sauvegarde pas de cache (`Swatinem/rust-cache`, `cache-on-failure` à false par défaut) : le cache partagé n'est pas touché. - **cargo-xwin** (Max) : épingler `cargo install --locked cargo-xwin --version <X.Y.Z>` dans `release.yml`, avec la dernière version stable publiée sur crates.io au moment du maillon, et ajouter une ligne `cargo-xwin --version` au journal. Raison : l'outil tourne dans l'étape qui porte `TAURI_SIGNING_PRIVATE_KEY`. Le relais de `-- --locked` par cargo-xwin n'est **pas** prouvé en local (SDK MSVC de plusieurs Go) : la PR le marque « à confirmer au prochain tag », et la vérification rejoint la liste de la release (le build Windows rougirait avant toute publication, l'updater ne bouge pas). - `CLAUDE.md`, section CI/CD : mentionner aussi l'épinglage de cargo-xwin. ## Review caveats - (Technique, corrigé) `check-rust` ne tourne pas sur un simple push de branche : d'où le `workflow_dispatch` ci-dessus. - (Sécurité, retenu) cargo-xwin non épinglé : traité par l'épinglage. ## Spec source spec-plan-lot-v018.md ## Note du 2026-10-18 : `REVIEW.md` est mergé Reprise du commentaire 24475, écrit avant le merge de `REVIEW.md` (PR #460, `main` `24da72b`). - La section « Commandes de vérification » de `REVIEW.md` décrit la CI sans `--locked` : la ligne `check-rust.yml` du tableau, les lignes `cargo check` et `cargo test` du bloc des commandes locales, et la phrase « `cargo check` et `cargo test` tournent sans `--locked` dans la CI ; #449 l'ajoute, et sa PR met ce tableau à jour. » La PR de cette issue ajoute `--locked` aux commandes du tableau et du bloc, puis retire cette phrase. Repérer ces passages par leur texte, pas par un numéro de ligne. - Selon `REVIEW.md`, cette PR est de niveau haut : elle modifie des étapes de verdict de `check-rust.yml` et touche `release.yml`. - `REVIEW.md` s'ajoute aux fichiers concernés.

maximus added the

status:triage

type:infra

source:human

labels 2026-10-16 23:12:57 +00:00

maximus referenced this issue

2026-10-16 23:17:17 +00:00

[security] deps: RUSTSEC-2026-0346 à -0349 (rustls) — l'audit quotidien est rouge depuis le 2026-10-15 #447

maximus added

status:ready

and removed

status:triage

labels 2026-10-16 23:40:14 +00:00

maximus referenced this issue

2026-10-17 00:13:24 +00:00

Garde des clés i18n : une clé présente dans une seule langue fait échouer npm test #453

maximus added this to the planned-2026-10-16-lot-v018 milestone 2026-10-17 00:14:23 +00:00

maximus referenced this issue

2026-10-17 00:14:24 +00:00

ui(paramètres): la liste complète des versions repousse le Journal tout en bas de Paramètres → Systèmes #372

maximus referenced this issue

2026-10-18 12:22:26 +00:00

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

maximus commented

2026-10-18 12:23:01 +00:00

Author

Owner

Note pour la PR de cette issue. REVIEW.md (PR #460, pas encore mergée) résume les commandes de la CI au 2026-10-17 et écrit, sous le tableau « Commandes de vérification » : « cargo check et cargo test tournent sans --locked dans la CI ; #449 l'ajoute, et sa PR met ce tableau à jour. »

Si #460 est mergée avant, la PR de #449 ajoute --locked aux commandes de ce tableau et du bloc des commandes locales, puis retire cette phrase. Selon les règles de #460, cette PR sera de niveau haut : elle modifie des étapes de verdict de check-rust.yml.

Note pour la PR de cette issue. `REVIEW.md` (PR #460, pas encore mergée) résume les commandes de la CI au 2026-10-17 et écrit, sous le tableau « Commandes de vérification » : « `cargo check` et `cargo test` tournent sans `--locked` dans la CI ; #449 l'ajoute, et sa PR met ce tableau à jour. » Si #460 est mergée avant, la PR de #449 ajoute `--locked` aux commandes de ce tableau et du bloc des commandes locales, puis retire cette phrase. Selon les règles de #460, cette PR sera de niveau haut : elle modifie des étapes de verdict de `check-rust.yml`.

maximus referenced this issue

2026-10-18 13:49:50 +00:00

fix(deps): build the updater without its zip feature to clear RUSTSEC-2026-0367 to -0369 #459

maximus referenced this issue

2026-10-18 21:18:51 +00:00

test(i18n): fail npm test on a key present in one language only (#453) #468

maximus added

status:in-progress

and removed

status:ready

labels 2026-10-18 21:22:21 +00:00

maximus referenced this issue from a commit