Skip to content

Workflow de release

Chaque repo publie ses images Docker uniquement sur tag Git. Pousser sur main ne déclenche plus de build Docker — seulement lint et tests.

Vue d'ensemble du pipeline

git tag v1.2.3 && git push origin v1.2.3


   GitHub Actions

   ┌─────┴──────┐
   │ lint        │  ← toujours actif (branches + tags)
   │ test        │
   └─────┬──────┘
         │ (si tag v*)
   ┌─────▼──────┐
   │ build-push │  → ghcr.io/healthai-corpo/<service>:1.2.3
   │            │  → ghcr.io/healthai-corpo/<service>:1.2
   │            │  → ghcr.io/healthai-corpo/<service>:1
   │            │  → ghcr.io/healthai-corpo/<service>:latest
   └─────┬──────┘

   ┌─────▼──────┐
   │  release   │  → GitHub Release avec CHANGELOG auto-généré
   └────────────┘

Créer une release

bash
# 1. S'assurer d'être sur main à jour
git checkout main
git pull

# 2. Créer le tag (respecter le format vMAJOR.MINOR.PATCH)
git tag v1.2.3

# 3. Pousser le tag — déclenche la CI
git push origin v1.2.3

C'est tout. La CI s'occupe du reste.

Tags Docker générés

Pour git tag v1.2.3, les images suivantes sont publiées :

TagUsage
:1.2.3Version exacte — immuable
:1.2Dernière patch de ce mineur
:1Dernière release du majeur
:latestDernière release stable

Versioning sémantique

Suivre semver.org :

Type de changementExemple
Correctif non-breakingv1.2.3v1.2.4
Nouvelle feature non-breakingv1.2.3v1.3.0
Changement breakingv1.2.3v2.0.0

Annuler un tag (si erreur avant push)

bash
# Supprimer en local
git tag -d v1.2.3

# Supprimer sur le remote (si déjà pushé)
git push origin --delete v1.2.3

Ne pas re-tagger

Éviter de re-créer un tag déjà pushé — l'image :1.2.3 ne sera pas reconstruite si elle existe déjà dans le registry.

CHANGELOG automatique

La GitHub Release est créée automatiquement avec le CHANGELOG généré par git-cliff.

Exemple de CHANGELOG généré :

markdown
## [1.2.0] - 2025-05-18

### Features
- (**auth**) Ajouter le support des refresh tokens
- Nouvelle page analytics utilisateurs

### Bug Fixes
- (**api**) Corriger la pagination des logs de santé

### Refactor
- Extraire la logique de validation dans un service dédié

git-cliff lit les commits depuis le tag précédent et groupe par catégorie. La qualité du CHANGELOG dépend directement de la convention de commits — voir Conventional Commits.

healthai-ai — build matrix

Le repo healthai-ai construit 3 images en parallèle sur le même tag :

git tag v1.0.0 && git push origin v1.0.0
  → healthai-vision:1.0.0
  → healthai-workout:1.0.0
  → healthai-ai-api:1.0.0

Les 3 images partagent le même numéro de version.