CI: Forgejo — split workflows + rust-cache + cargo-audit pre-buildt #232

New issue

Open

opened 2026-07-01 00:06:22 +00:00 by maximus · 2 comments

maximus commented

2026-07-01 00:06:22 +00:00

Owner

Refs: spec-decisions-ci-build-optimization.md + spec-plan-ci-build-optimization.md — RE-SEQUENCE post-baseline #231 (2026-06-30).

La baseline #231 a confirme la cause #2 (save du cache echoue : reserveCache failed: Request timeout). Consequence : rust-cache ne peut PAS aider tant que #234 (connectivite serveur-de-cache du runner, acces hote VPS) n'est pas fait — il partage le meme backend reserveCache. Cette issue fait donc les GAINS IMMEDIATS (sans VPS) ; rust-cache est defere a un follow-up apres #234.

Gains immediats (sans acces VPS) — cible : PR Rust ~11-12 min (au lieu de 24), PR frontend ~3 min

Split .forgejo/workflows/check.yml -> check-rust.yml + check-frontend.yml.
check-rust.yml : on.pull_request.branches:[main] + paths:[src-tauri/**, self] ; concurrency DISTINCT (ci-rust-${{ github.ref }}) ; permissions: contents: read ; etape « install sysdeps + Node.js + toolchain » verbatim ; env CARGO_INCREMENTAL=0 / CARGO_PROFILE_TEST_DEBUG=0.
RETIRER le cache target/ manuel : il gaspille ~7 min/run en saves rates (reserveCache timeout), inutile tant que #234 n'est pas fait. (Cache registry+git : le retirer aussi ou le garder, marginal.)
cargo-audit via taiki-e/install-action (binaire, ~5.5 min gagnees) au lieu de cargo install ; SANS || true ; + un on: schedule quotidien pour la couverture RustSec hors PR Rust.
check-frontend.yml : job frontend inchange (+ commentaire « cache npm manuel volontaire ») ; branches:[main] + paths: frontend ; concurrency DISTINCT (ci-frontend-${{ github.ref }}) ; permissions: contents: read.
PR de controle go/no-go : PR touchant src-tauri/** -> check-rust ; PR frontend-only -> check-rust SAUTE.

Defere (follow-up apres #234)

Ajouter Swatinem/rust-cache@v2 (workspaces: "src-tauri -> target") une fois la connectivite serveur-de-cache reparee (#234) -> cache reellement persiste + prune. Verifier alors un vrai Cache restored au run suivant.

Depends on #231 (baseline, fait). Prerequis pour rust-cache : #234.

Refs: spec-decisions-ci-build-optimization.md + spec-plan-ci-build-optimization.md — **RE-SEQUENCE post-baseline #231 (2026-06-30)**. La baseline #231 a confirme la **cause #2** (save du cache echoue : `reserveCache failed: Request timeout`). Consequence : **rust-cache ne peut PAS aider tant que #234 (connectivite serveur-de-cache du runner, acces hote VPS) n'est pas fait** — il partage le meme backend `reserveCache`. Cette issue fait donc les GAINS IMMEDIATS (sans VPS) ; rust-cache est defere a un follow-up apres #234. ### Gains immediats (sans acces VPS) — cible : PR Rust ~11-12 min (au lieu de 24), PR frontend ~3 min - [ ] Split `.forgejo/workflows/check.yml` -> `check-rust.yml` + `check-frontend.yml`. - [ ] `check-rust.yml` : `on.pull_request.branches:[main]` + `paths:[src-tauri/**, self]` ; `concurrency` DISTINCT (`ci-rust-${{ github.ref }}`) ; `permissions: contents: read` ; etape « install sysdeps + Node.js + toolchain » **verbatim** ; env `CARGO_INCREMENTAL=0` / `CARGO_PROFILE_TEST_DEBUG=0`. - [ ] **RETIRER le cache `target/` manuel** : il gaspille ~7 min/run en saves rates (`reserveCache timeout`), inutile tant que #234 n'est pas fait. (Cache registry+git : le retirer aussi ou le garder, marginal.) - [ ] `cargo-audit` via `taiki-e/install-action` (binaire, ~5.5 min gagnees) au lieu de `cargo install` ; SANS `|| true` ; + un `on: schedule` quotidien pour la couverture RustSec hors PR Rust. - [ ] `check-frontend.yml` : job frontend inchange (+ commentaire « cache npm manuel volontaire ») ; `branches:[main]` + `paths:` frontend ; `concurrency` DISTINCT (`ci-frontend-${{ github.ref }}`) ; `permissions: contents: read`. - [ ] PR de controle **go/no-go** : PR touchant `src-tauri/**` -> check-rust ; PR frontend-only -> check-rust SAUTE. ### Defere (follow-up apres #234) - [ ] Ajouter `Swatinem/rust-cache@v2` (`workspaces: "src-tauri -> target"`) une fois la connectivite serveur-de-cache reparee (#234) -> cache reellement persiste + prune. Verifier alors un vrai `Cache restored` au run suivant. Depends on #231 (baseline, fait). Prerequis pour rust-cache : #234.

maximus added this to the spec-ci-build-optimization milestone 2026-07-01 00:06:22 +00:00

maximus added the

status:ready

type:infra

source:human

labels 2026-07-01 00:06:22 +00:00

maximus referenced this issue

2026-07-01 00:06:23 +00:00

CI: miroir GitHub — meme restructuration (split + rust-cache) #233

maximus commented

2026-07-01 00:37:55 +00:00

Author

Owner

Ajustements issus de /review-spec (2026-06-30) — à intégrer en plus du body :

🔴 Concurrency : chaque fichier splitté doit re-déclarer on.pull_request.branches:[main] ET un groupe concurrency DISTINCT (ci-rust-${{ github.ref }} / ci-frontend-${{ github.ref }}). Sinon, en héritant de ci-${{ github.ref }} + cancel-in-progress, les 2 workflows s'annulent mutuellement sur une PR mixte.
Conserver l'étape « install sysdeps + Node.js + toolchain » verbatim dans check-rust : rust-cache et taiki-e/install-action sont des actions JS qui exigent node dans le PATH.
Ajouter permissions: contents: read en tête de chaque nouveau workflow.
cargo-audit : ajouter un on: schedule quotidien (ou un workflow audit dédié sans paths:) pour garder la couverture RustSec hors des PR Rust ; retirer le || true (échouer sur erreur d'outillage, advisories non-bloquantes).
paths rust = src-tauri/** + self (retirer les globs **/*.rs redondants — tout le Rust est sous src-tauri/).
Dépendance assouplie : baseline (#231) capturée AVANT le merge, sinon parallélisable.

Détail : spec-plan-ci-build-optimization.md → Issue 2 + « Revision — Synthese ».

Ajustements issus de /review-spec (2026-06-30) — à intégrer en plus du body : - 🔴 **Concurrency** : chaque fichier splitté doit re-déclarer `on.pull_request.branches:[main]` ET un groupe `concurrency` DISTINCT (`ci-rust-${{ github.ref }}` / `ci-frontend-${{ github.ref }}`). Sinon, en héritant de `ci-${{ github.ref }}` + `cancel-in-progress`, les 2 workflows s'annulent mutuellement sur une PR mixte. - Conserver l'étape « install sysdeps + Node.js + toolchain » **verbatim** dans check-rust : rust-cache et taiki-e/install-action sont des actions JS qui exigent `node` dans le PATH. - Ajouter `permissions: contents: read` en tête de chaque nouveau workflow. - cargo-audit : ajouter un `on: schedule` quotidien (ou un workflow audit dédié sans `paths:`) pour garder la couverture RustSec hors des PR Rust ; retirer le `|| true` (échouer sur erreur d'outillage, advisories non-bloquantes). - paths rust = `src-tauri/** + self` (retirer les globs `**/*.rs` redondants — tout le Rust est sous src-tauri/). - Dépendance assouplie : baseline (#231) capturée AVANT le merge, sinon parallélisable. Détail : spec-plan-ci-build-optimization.md → Issue 2 + « Revision — Synthese ».

maximus referenced this issue

2026-07-01 00:45:49 +00:00

CI: baseline & diagnostic du job rust #231

maximus referenced this issue

2026-07-01 00:45:49 +00:00

CI: connectivité serveur-de-cache du runner (reserveCache timeout — cause #2) #234

maximus commented

2026-07-01 00:45:49 +00:00

Author

Owner

Ré-orientation suite à la baseline #231 : la cause dominante est #2 (save échoue, reserveCache timeout), pas #1. rust-cache seul ne débloquera PAS les 24 min — il partage le backend reserveCache.

→ Prérequis : #234 (connectivité serveur-de-cache du runner, accès hôte VPS). Une fois #234 résolu, rust-cache reprend tout son sens (cache pruné + réellement persisté).

Restent applicables indépendamment dans cette issue (gains immédiats, sans dépendre de #234) : cargo-audit en binaire pré-buildé (~5.5 min/run), path-filter (skip rust sur PR frontend), + le fix concurrency/permissions/install-Node de la revue. À reséquencer : ces gains d'abord, rust-cache après #234.

Ré-orientation suite à la baseline #231 : la cause dominante est **#2 (save échoue, `reserveCache timeout`)**, pas #1. **rust-cache seul ne débloquera PAS les 24 min** — il partage le backend `reserveCache`. → Prérequis : #234 (connectivité serveur-de-cache du runner, accès hôte VPS). Une fois #234 résolu, rust-cache reprend tout son sens (cache pruné + réellement persisté). Restent applicables **indépendamment** dans cette issue (gains immédiats, sans dépendre de #234) : **cargo-audit en binaire pré-buildé** (~5.5 min/run), **path-filter** (skip rust sur PR frontend), + le fix concurrency/permissions/install-Node de la revue. À reséquencer : ces gains d'abord, rust-cache après #234.