maximus/Simpl-Resultat
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases 29 Packages Wiki Activity Actions
Simpl-Resultat/.claude/skills/release/SKILL.md
le king fu 7779f7dc52
All checks were successful
PR Check — Frontend / frontend (pull_request) Successful in 1m44s
Details
PR Check — Rust / rust (pull_request) Successful in 9m6s
Details
ci: ignore .claude/ in the frontend filter, drop stale check.yml ref 
Follow-up on the review of #232:

- .claude/ is tracked (rules + skills) and cannot affect the frontend build,
  so a change confined to it no longer queues a 1m43s job for nothing.
- The release skill's pre-flight step named check.yml, which this PR deletes.
  The reasoning still holds — the check workflows only run on PRs, never on
  main, so a merged tip has never been seen by CI — only the filename moved.
  Its dated changelog entry is left alone.

Resolves #232
2026-07-24 21:02:12 -04:00

4.7 KiB
Raw Blame History

name description user-invocable updated
release Release a new version of Simpl-Resultat (bump, changelog, tag, push) true 2026-07-13

/release — Release Simpl-Resultat

Context injection

  1. Lire version dans src-tauri/Cargo.toml et package.json
  2. Lister les derniers tags : git tag --sort=-v:refname | head -10
  3. Lire CHANGELOG.md et CHANGELOG.fr.md (dernieres entrees)

Workflow

  1. Pré-vol — revalider le tip localement. Les workflows check-rust.yml / check-frontend.yml ne tournent pas sur main : le tip mergé n'a jamais été vu par le CI (le dernier run vert portait sur la branche d'issue avant merge), et le tag grave ce tip exact dans des binaires distribués. Lancer npm run build && npm test (vitest) + cd src-tauri && cargo check && cargo test. Vérifier aussi que .claude/worktrees/ est vide (worktrees leftover → vitest récurse et gonfle le compteur). Ne tagger que sur un tip vert.
  2. Determiner la nouvelle version (argument utilisateur ou demander)
  3. Bump version dans les 5 fichiers :
    • src-tauri/Cargo.toml (ligne version = "...")
    • src-tauri/Cargo.lock (bloc [[package]] name = "simpl-result" + sa ligne version = "..." ; ne PAS regenerer avec cargo)
    • src-tauri/tauri.conf.json (champ "version")
    • package.json (champ "version")
    • package-lock.json (deux champs "version" — root ~ligne 3 et le package racine "" ~ligne 9)
      • Si package-lock.json est stale (hygiene warning package-lock.json plus ancien que package.json) : npm install --package-lock-only --no-audit --no-fund pour resync. Note : peut ajouter des entrees bundled optionnelles (tailwindcss oxide wasm etc.) — cosmetique, pas d'install effective.
  4. Mettre a jour les 2 changelogs — format Keep a Changelog :
    • CHANGELOG.md (EN) : header ## [Unreleased]
    • CHANGELOG.fr.md (FR) : header ## [Non publié] (PAS [Unreleased] — ne pas le confondre avec un changelog vide)
    • Pattern de migration : transformer le header « non publié » de chaque fichier en ## [X.Y.Z] - YYYY-MM-DD, puis recreer la section « non publié » vide au-dessus pour accueillir les prochaines entrees. Le header differe selon la langue. Ne pas deplacer le contenu — les sections sont laissees en place.
  5. Si changement d'architecture : mettre a jour docs/architecture.md
  6. Commit : chore: release vX.Y.Z (ajouter les 7 fichiers : 5 bumps + 2 changelogs)
  7. Tag annote (permet une release notes par tag, lisible via git show vX.Y.Z) : 
    git tag -a vX.Y.Z -m "Release X.Y.Z

- <bullet highlights>"
  8. Push : git push origin main && git push origin vX.Y.Z
  9. Forgejo CI build automatique (Windows + Linux) via release.yml sur on: push: tags: v*
  10. Post-CI — vérifier la release publiée. Surveiller release.yml (outil Monitor sur le run), puis vérifier la release réellement attachée — status=success du workflow ne suffit pas :
    • Les 7 artefacts attendus : .exe NSIS, .deb, .rpm, leurs 3 signatures .sig, et latest.json.
    • Le contenu de latest.json (il pilote l'auto-update des installations existantes) : champ version correct, signatures non vides pour les deux plateformes, URLs pointant vers les bons binaires, notes extraites du CHANGELOG.

Regles

  • JAMAIS git push --tags — toujours push le tag individuellement
  • Toujours mettre a jour les 2 changelogs (EN + FR)
  • Format Keep a Changelog : ## [X.Y.Z] - YYYY-MM-DD
  • Les changelogs sont bundles dans public/ pour l'affichage in-app
  • Tag annote (-a), pas lightweight : les artefacts CI reference le tag pour les release notes
  • Tagger publie vers l'extérieur : release.yml pousse le JSON d'updater, donc les utilisateurs installés reçoivent la mise à jour automatiquement. Confirmer avec Max avant de tagger.

Changelog

  • 2026-04-19 — Added Cargo.lock + package-lock.json to bump list, npm install --package-lock-only fallback when lockfile stale, explicit [Unreleased] migration pattern, annotated tags (#102/#112 release cycle)
  • 2026-07-01 — Documenter que le header FR est ## [Non publié] (≠ [Unreleased]), pour éviter le faux diagnostic « changelog FR vide » lors de la migration. Source : session 5466da98.
  • 2026-07-13 — Étape 0 (pré-vol) : revalider le tip localement avant de tagger — check.yml ne tourne pas sur main, le tip mergé n'a jamais été vu par le CI ; vérifier .claude/worktrees/ vide (vitest récurse sinon). Étape 9 (post-CI) : vérifier la release publiée — 7 artefacts attendus + contenu de latest.json (pilote l'auto-update) ; status=success ne suffit pas. Règle : tagger publie vers l'extérieur (updater automatique) → confirmer avec Max avant de tagger. Source : session fdda84cb (release v0.13.0).