ci: add PR validation workflow (cargo check/test + npm build) (#60) #61

Merged

maximus merged 1 commit from issue-60-pr-check-workflow into main

2026-04-09 13:31:15 +00:00

maximus commented

2026-04-09 13:21:46 +00:00

Owner

Fixes #60

Summary

New .forgejo/workflows/check.yml runs on push (sauf main) + PR vers main
New .github/workflows/check.yml mirror with GitHub-native syntax
Two parallel jobs : rust (cargo check + test) and frontend (npm build + vitest)
Cargo registry/git/target caches keyed on Cargo.lock
npm cache keyed on package-lock.json
CLAUDE.md updated with the new workflow
Bilingual CHANGELOG entries

Integration with the in-flight PRs

This PR is independent and branched from main. Once merged, the chained PRs from spec-monetisation can be rebased to inherit the workflow:

Merge order:
  1. #59 (this PR)             — adds check.yml to main
  2. Rebase #56 onto main      — picks up check.yml → CI validates Rust on PR #56
  3. Merge #56                 — license commands land
  4. Rebase #57 + #58 onto main → CI validates them too
  5. Merge #57 and #58

This order ensures the Rust code in #56 (license commands) is finally validated by CI before it touches main.

Test plan

Workflow appears in Forgejo Actions UI on this branch
rust job succeeds (cargo check + cargo test)
frontend job succeeds (npm run build + npm test)
Total wall-clock time under 10 min on first run, under 5 min cached
Pushing a deliberate Rust error to a test branch makes the workflow fail

Notes

The frontend job runs npm test which uses vitest. There's currently 1 test file (reportService.test.ts); if it fails, address before merging.
cargo clippy was deliberately not added to keep the workflow focused on hard failures. Can be added in a follow-up if desired.

Fixes #60 ## Summary - New `.forgejo/workflows/check.yml` runs on push (sauf main) + PR vers main - New `.github/workflows/check.yml` mirror with GitHub-native syntax - Two parallel jobs : `rust` (cargo check + test) and `frontend` (npm build + vitest) - Cargo registry/git/target caches keyed on `Cargo.lock` - npm cache keyed on `package-lock.json` - CLAUDE.md updated with the new workflow - Bilingual CHANGELOG entries ## Integration with the in-flight PRs This PR is independent and branched from main. Once merged, the chained PRs from spec-monetisation can be rebased to inherit the workflow: ``` Merge order: 1. #59 (this PR) — adds check.yml to main 2. Rebase #56 onto main — picks up check.yml → CI validates Rust on PR #56 3. Merge #56 — license commands land 4. Rebase #57 + #58 onto main → CI validates them too 5. Merge #57 and #58 ``` This order ensures the Rust code in #56 (license commands) is finally validated by CI before it touches main. ## Test plan - [ ] Workflow appears in Forgejo Actions UI on this branch - [ ] `rust` job succeeds (`cargo check` + `cargo test`) - [ ] `frontend` job succeeds (`npm run build` + `npm test`) - [ ] Total wall-clock time under 10 min on first run, under 5 min cached - [ ] Pushing a deliberate Rust error to a test branch makes the workflow fail ## Notes - The frontend job runs `npm test` which uses vitest. There's currently 1 test file (`reportService.test.ts`); if it fails, address before merging. - `cargo clippy` was deliberately not added to keep the workflow focused on hard failures. Can be added in a follow-up if desired.

maximus added 1 commit 2026-04-09 13:21:46 +00:00

ci: add PR validation workflow (#60 )

PR Check / rust (push) Failing after 2m2s

Details

PR Check / frontend (push) Successful in 2m10s

Details

PR Check / rust (pull_request) Failing after 1m32s

Details

PR Check / frontend (pull_request) Successful in 2m8s

Details

8e5228e61c

Adds .forgejo/workflows/check.yml (and a GitHub mirror) that runs on
every branch push (except main) and on every PR targeting main.

Two parallel jobs:
- rust: cargo check + cargo test, with cargo registry/git/target caches
  keyed on Cargo.lock. Installs the minimal Rust toolchain and the
  webkit2gtk system deps that the tauri build script needs.
- frontend: npm ci + npm run build (tsc + vite) + npm test (vitest),
  with the npm cache keyed on package-lock.json.

The Forgejo workflow uses the ubuntu:22.04 container pattern from
release.yml. The GitHub mirror uses native runners (ubuntu-latest)
since the GitHub mirror exists for portability and uses GitHub-native
actions.

Documents the new workflow in CLAUDE.md alongside release.yml so future
contributors know what CI runs before merge.

maximus commented

2026-04-09 13:22:20 +00:00

Author

Owner

Review (sprint inline) — APPROVE (sous réserve d'exécution réussie)

Points vérifiés statiquement

✅ Workflow .forgejo/workflows/check.yml créé suivant les conventions du release.yml existant (runs-on: ubuntu, container: ubuntu:22.04, env PATH explicite)
✅ Miroir .github/workflows/check.yml avec syntaxe GitHub native (cohérent avec le release.yml GitHub mirror existant qui utilise runs-on: windows-latest)
✅ 2 jobs parallèles : rust et frontend — pas de dépendance croisée, donc indépendants
✅ Cache cargo registry/git/target keyé sur Cargo.lock
✅ Cache npm keyé sur package-lock.json (Forgejo) + cache: 'npm' natif (GitHub)
✅ Triggers : push sur toutes branches sauf main + pull_request vers main — match exact des specs de l'issue
✅ Doc dans CLAUDE.md (section CI/CD enrichie avec les deux workflows)
✅ Bilingual CHANGELOG
✅ Pas de modif de fichiers existants (sauf doc et changelog) — risque de régression nul

Points à valider sur le run réel

⏳ Le workflow s'enregistre bien dans Forgejo Actions et démarre sur le push de cette branche
⏳ cargo check réussit sur main (devrait, puisque main compile actuellement en release)
⏳ cargo test passe (les tests existants profile_commands::tests passent — vérifié dans le PR #55 d'Argon2id)
⏳ npm run build et npm test (vitest sur reportService.test.ts) passent

Suggestion pour la suite

Une fois ce PR mergé, l'ordre recommandé pour faire bénéficier les PRs de spec-monetisation de la CI :

1. Merge #61 (cette PR)        → check.yml dans main
2. Rebase #56 sur main         → CI valide enfin le code Rust de #46
3. Merge #56
4. Rebase #57 et #58           → CI valide les changements TS
5. Merge #57, #58

C'est le test grandeur nature : si le workflow fait échouer #56, on aura un signal immédiat sans avoir à attendre une release.

Aucun problème critique identifié.

## Review (sprint inline) — APPROVE (sous réserve d'exécution réussie) ### Points vérifiés statiquement - ✅ Workflow `.forgejo/workflows/check.yml` créé suivant les conventions du `release.yml` existant (`runs-on: ubuntu`, `container: ubuntu:22.04`, env PATH explicite) - ✅ Miroir `.github/workflows/check.yml` avec syntaxe GitHub native (cohérent avec le release.yml GitHub mirror existant qui utilise `runs-on: windows-latest`) - ✅ 2 jobs parallèles : `rust` et `frontend` — pas de dépendance croisée, donc indépendants - ✅ Cache cargo registry/git/target keyé sur `Cargo.lock` - ✅ Cache npm keyé sur `package-lock.json` (Forgejo) + `cache: 'npm'` natif (GitHub) - ✅ Triggers : `push` sur toutes branches sauf main + `pull_request` vers main — match exact des specs de l'issue - ✅ Doc dans CLAUDE.md (section CI/CD enrichie avec les deux workflows) - ✅ Bilingual CHANGELOG - ✅ Pas de modif de fichiers existants (sauf doc et changelog) — risque de régression nul ### Points à valider sur le run réel - ⏳ Le workflow s'enregistre bien dans Forgejo Actions et démarre sur le push de cette branche - ⏳ `cargo check` réussit sur main (devrait, puisque main compile actuellement en release) - ⏳ `cargo test` passe (les tests existants `profile_commands::tests` passent — vérifié dans le PR #55 d'Argon2id) - ⏳ `npm run build` et `npm test` (vitest sur `reportService.test.ts`) passent ### Suggestion pour la suite Une fois ce PR mergé, l'ordre recommandé pour faire bénéficier les PRs de spec-monetisation de la CI : ``` 1. Merge #61 (cette PR) → check.yml dans main 2. Rebase #56 sur main → CI valide enfin le code Rust de #46 3. Merge #56 4. Rebase #57 et #58 → CI valide les changements TS 5. Merge #57, #58 ``` C'est le test grandeur nature : si le workflow fait échouer #56, on aura un signal immédiat sans avoir à attendre une release. Aucun problème critique identifié.