Holix release (faire une release)

Holix release («сделай релиз»)

Lorsque l'utilisateur dit faire une release (ou équivalent), exécute ce pipeline en entier. Ne t'arrête pas après la PR. Ne saute pas la CI. Ne crée pas de tag avant la fusion.

Règles canoniques du paquet : RULES.md §8. Cette compétence est la boucle opérationnelle.

Préconditions

• Dépôt : javded-itres/Holix. Branche par défaut : main.
• Authentification : gh auth status doit être connecté.
• Récupère d'abord : git fetch origin --tags.
• Version suivante = dernière release GitHub + patch (1.0.7 → 1.0.8), sauf si l'utilisateur a demandé mineur/majeur.
• Vérifie que les versions concordent avant de taguer :
  • pyproject.toml [project].version
  • cli/__init__.py __version__
  • dernière gh release list / git tag
• Ne pas rsync/scp/hotfix en production. Tagger sur main suffit : GHA GitHub Release + Publish to PyPI s'exécutent à partir de vX.Y.Z.
• Exécute ./scripts/lint.sh (ou --fix) avant chaque push.

1) PR avec les modifications

Inclure code + mise à jour de version + journal des modifications dans la même PR pour qu'il y ait une seule fusion, puis un tag.

1. Si une PR ouverte couvre déjà ce travail, réutilise-la et ajoute la mise à jour de version si elle manque.
2. Sinon, crée une branche à partir de origin/main à jour : release/X.Y.Z (exemple : release/1.0.8).
3. Valide le travail non validé/non fusionné de l'utilisateur (pas de secrets, pas de node_modules/, pas de .env local).
4. Mise à jour de version avec scripts/versioning.py (ou modifie les deux fichiers) :
   • pyproject.toml
   • cli/__init__.py
5. Met à jour docs/CHANGELOG.md :
   • Déplace les notes de ## Unreleased dans ## X.Y.Z — YYYY-MM-DD
   • Laisse un nouveau ## Unreleased vide
   • Écris Ajouté/Corrigé/Tests à partir du diff réel
6. Pousse et ouvre une PR → main :

gh pr create --base main --title "Holix X.Y.Z" --body "$(cat <<'EOF'
## Résumé
Publication de Holix X.Y.Z.

## Liste de vérification
- [ ] La version correspond dans pyproject.toml et cli/__init__.py
- [ ] docs/CHANGELOG.md contient la section X.Y.Z
- [ ] CI verte (ruff + matrix pytest)

Après fusion : tag `vX.Y.Z` (crée GitHub Release + PyPI).
EOF
)"

2) Tests GitHub jusqu'à ce qu'ils soient verts

Surveille GitHub Actions sur la PR, pas seulement pytest local.

gh pr checks <n> --watch
# ou
gh run watch <run-id>

En cas d'échec :

1. gh run view <id> --log-failed (ou logs du job).
2. Corrige le code / les tests / ruff.
3. Localement : ./scripts/lint.sh puis pytest ciblé.
4. Valide, pousse, ré-examine.

Répète jusqu'à ce que toute vérification requise soit verte. Ne fusionne pas une CI rouge. Si un échec nécessite une décision produit, arrête-toi et demande — ne passe pas outre.

3) Fusion dans main

L'utilisateur a déjà autorisé la fusion dans le cadre de cette commande.

gh pr merge <n> --merge --delete-branch

Utilise --squash uniquement si l'utilisateur l'a demandé. Attends que la PR soit MERGED. Ensuite git checkout main && git pull origin main.

Vérifie que main a maintenant la version X.Y.Z.

4) Prochaine release GitHub numérotée

Le tag doit correspondre à pyproject.toml. Ne crée pas de release GitHub à la main si le workflow de tag peut le faire.

git checkout main
git pull origin main
python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])"
git tag vX.Y.Z
git push origin vX.Y.Z

Surveille :

• GitHub Release → https://github.com/javded-itres/Holix/releases/tag/vX.Y.Z
• Publish to PyPI

gh run list --branch vX.Y.Z --limit 5
gh release view vX.Y.Z

Si le workflow de tag échoue parce que le CHANGELOG n'a pas de section ## X.Y.Z, corrige sur une PR suivante, supprime/re-pousse le tag uniquement avec --force-with-lease après l'avoir dit. Préfère un nouveau patch à la réécriture d'un tag publié.

Rapport

Quand c'est terminé, réponds avec :

• URL de la PR et SHA de fusion
• Version X.Y.Z / tag vX.Y.Z
• URL de la Release
• Statut du workflow CI + PyPI