Crée des tags annotés et prépare une release

L’idée reçue

« Une branche release et une release GitHub sont la même chose. »

La branche sert à préparer. Le tag identifie un commit immuable. La release GitHub ajoute une page, des notes et éventuellement des fichiers autour de ce tag.

01Identifie le commit à livrer

git switch main
git pull --ff-only origin main
git status --short --branch
git log -1 --format='commit=%H%nsubject=%s%nauthor=%an'

Ne crée pas le tag sur « ce qui semble être main ». Conserve le SHA exact qui a passé les validations et qui correspond au déploiement attendu.

02Choisis une version explicite

v1.4.2
│ │ └── correction compatible
│ └──── fonctionnalité compatible
└────── changement majeur incompatible

Le numéro ne remplace pas les notes de release. Une équipe doit aussi documenter son propre contrat de compatibilité.

03Crée un tag annoté

git tag -a v1.0.0 \
  -m "SORIA Agent 1.0.0" \
  "$(git rev-parse main)"

git cat-file -t v1.0.0
git show --no-patch --format=fuller v1.0.0
git rev-list -n 1 v1.0.0

Le type doit être tag, pas seulement commit. Le tag annoté porte sa propre identité, sa date et son message.

04Prépare les notes de release

# Version 1.0.0

## Added
- health check ;
- configuration du délai.

## Validation
- syntaxe du script ;
- scénario fonctionnel ;
- checksum de l’archive.

## Known limits
- validation Linux uniquement.

## Rollback
Revenir au tag précédent puis redéployer.

05Construis un artefact reproductible

mkdir -p dist
tar -czf dist/soria-agent-1.0.0.tar.gz README.md src/
sha256sum dist/soria-agent-1.0.0.tar.gz \
  > dist/SHA256SUMS
sha256sum -c dist/SHA256SUMS

Le checksum détecte une différence de fichier. Il ne démontre ni l’identité de l’auteur ni l’absence de logiciel malveillant.

06Publie le tag puis la release

git push origin v1.0.0

gh release create v1.0.0 \
  dist/soria-agent-1.0.0.tar.gz \
  dist/SHA256SUMS \
  --verify-tag \
  --title "SORIA Agent 1.0.0" \
  --notes-file docs/RELEASE_NOTES_1.0.0.md

–verify-tag évite de fabriquer implicitement un tag au mauvais endroit. Vérifie encore le SHA distant après publication.

07Contrôle la livraison

git ls-remote --tags origin v1.0.0
gh release view v1.0.0
gh release verify-asset v1.0.0 \
  dist/soria-agent-1.0.0.tar.gz

Preuve

Ce qu’elle démontre

Limite

SHA du tag

commit ciblé

ne prouve pas le test

CI verte

checks exécutés

seulement leur périmètre

checksum

intégrité du fichier

pas la confiance

notes

intention et limites

doivent rester exactes

08Évite de déplacer une version publiée

Mauvaise pratique
- supprimer puis recréer v1.0.0 sur un autre commit ;
- remplacer silencieusement un asset ;
- conserver le même numéro pour deux contenus.

Après publication, corrige avec une nouvelle version. Déplacer un tag partagé détruit la correspondance entre historique, artefacts et utilisateurs.

Mission

Prépare une release vérifiable

Exécute le scénario release du lab. Remets le SHA ciblé, le type du tag, les notes, le checksum et une procédure de rollback.

✓À retenir

Une release relie un commit exact, un tag annoté, des validations déclarées, des artefacts contrôlés et un rollback. Aucun de ces éléments ne doit être implicite.