From db625d02efc015ab8ef0ca28d84bbed79f5a7036 Mon Sep 17 00:00:00 2001 From: le king fu Date: Sun, 18 Oct 2026 17:39:11 -0400 Subject: [PATCH] docs: record the proven --locked relay of both release runners (#449) - Release skill, step 2: quote the refusal cargo actually prints, the same under cargo 1.94.1 and 1.99.1 (`cannot update the lock file ... because --locked was passed to prevent this`, code 101). - docs/architecture.md: the relay of --locked is proven for both runners on a lockfile out of step with Cargo.toml: cargo-xwin 0.23.1 runs `cargo build ... --locked ...`, and the other cargo calls of the Tauri CLI and cargo-xwin are `cargo metadata --no-deps`, which never touch the lockfile. Resolves #449 Co-Authored-By: Claude Opus 5.5 --- .claude/skills/release/SKILL.md | 2 +- docs/architecture.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.claude/skills/release/SKILL.md b/.claude/skills/release/SKILL.md index abe31fd..a34eff7 100644 --- a/.claude/skills/release/SKILL.md +++ b/.claude/skills/release/SKILL.md @@ -30,7 +30,7 @@ updated: 2026-10-18 ```bash cargo metadata --manifest-path src-tauri/Cargo.toml --format-version 1 --locked > /dev/null ``` - Attendu : code de sortie 0 (avec `--locked`, cargo n'écrit jamais le lock). Un refus (`the lock file … needs to be updated but --locked was passed to prevent this`) veut dire que l'édition à la main ne correspond pas à `Cargo.toml` (version de `simpl-result` différente des deux côtés, strophe abîmée) : corriger le lock à la main, ne jamais le régénérer avec cargo. + Attendu : code de sortie 0 (avec `--locked`, cargo n'écrit jamais le lock). Un refus (code 101, `error: cannot update the lock file … because --locked was passed to prevent this`) veut dire que l'édition à la main ne correspond pas à `Cargo.toml` (version de `simpl-result` différente des deux côtés, strophe abîmée) : corriger le lock à la main, ne jamais le régénérer avec cargo. - Puis rejouer le garde `windows-sys` de `check-rust.yml` sur le lock édité : le commit de release touche `Cargo.lock` directement sur `main`, sans PR, et `check-rust` ne le verrait qu'au lundi suivant, après le build du tag ([ADR 0023](../../../docs/adr/0023-windows-sys-pinning.md)). Depuis la racine du dépôt, le texte exact de l'étape avec les options du runner : ```bash python3 -c 'import sys, yaml; steps = yaml.safe_load(open(".forgejo/workflows/check-rust.yml"))["jobs"]["rust"]["steps"]; sys.stdout.write(next(s["run"] for s in steps if s.get("name") == "Verify windows-sys pinning"))' \ diff --git a/docs/architecture.md b/docs/architecture.md index 1ecbb7f..b56a2f3 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -691,7 +691,7 @@ Fonctionnalités : **Node.js 24** ([#376](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/376)), installé comme dans les trois autres workflows par le script NodeSource (`curl … | bash`). Ce script tourne en root dans le conteneur du job, et le Node.js qu'il installe lance ensuite `npx tauri build` avec `TAURI_SIGNING_PRIVATE_KEY` dans son environnement : le job confie à NodeSource (script et dépôt apt) la clé de signature de l'updater, et les jetons de publication des étapes suivantes. Risque accepté par Max le 2026-10-10, alternative écartée : un tarball Node.js épinglé. La chaîne Rust, installée de la même façon par `rustup`, est dans le même cas. Ce workflow ne tourne qu'au tag : la première release après #376 est la première sous Node 24, à vérifier par `node --version` dans le journal du run (étape 9 de `/release`). -**Lock commité, cargo-xwin épinglé** ([#449](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/449)). Les deux `npx tauri build` passent `-- --locked` : la CLI de Tauri transmet ce qui suit `--` à son runner, cargo pour Linux, cargo-xwin pour Windows, qui le passe à `cargo build`. Les binaires livrés sont donc bâtis sur le `Cargo.lock` commité, ou le build échoue au lieu de le réécrire ; l'étape 2 de `/release`, qui édite le lock à la main sur `main` sans PR, vérifie ce lock par `cargo metadata --locked` avant le tag. Le journal du run n'imprime jamais la ligne de commande de cargo : la preuve que le drapeau arrive est un lock désaccordé qui fait échouer le build, faite en local dans la PR de #449. cargo-xwin, qui tourne avec `TAURI_SIGNING_PRIVATE_KEY` dans son environnement, est installé en version fixe (`cargo install --locked cargo-xwin --version 0.23.1`, celle qu'avait installée la release v0.17.2), et l'étape affiche `cargo-xwin --version` ; une nouvelle version se décide, après lecture de ce qu'elle change. +**Lock commité, cargo-xwin épinglé** ([#449](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/449)). Les deux `npx tauri build` passent `-- --locked` : la CLI de Tauri transmet ce qui suit `--` à son runner, cargo pour Linux, cargo-xwin pour Windows, qui le passe à `cargo build`. Les binaires livrés sont donc bâtis sur le `Cargo.lock` commité, ou le build échoue au lieu de le réécrire ; l'étape 2 de `/release`, qui édite le lock à la main sur `main` sans PR, vérifie ce lock par `cargo metadata --locked` avant le tag. Le journal du run n'imprime jamais la ligne de commande de cargo : la preuve que le drapeau arrive est un lock désaccordé qui fait échouer le build, faite en local dans la PR de #449 pour les deux runners (cargo-xwin 0.23.1 lance `cargo build … --locked …`, et les autres appels à cargo de la CLI et de cargo-xwin sont des `cargo metadata --no-deps`, qui ne touchent pas au lock). cargo-xwin, qui tourne avec `TAURI_SIGNING_PRIVATE_KEY` dans son environnement, est installé en version fixe (`cargo install --locked cargo-xwin --version 0.23.1`, celle qu'avait installée la release v0.17.2), et l'étape affiche `cargo-xwin --version` ; une nouvelle version se décide, après lecture de ce qu'elle change. ## Architecture Decision Records (ADRs)