chore: release protocol

Closes #128

Ce qui change

• utilisation de release-it, un outil fort éprouvé et configurable
• trigger de la pipeline release (changelog -> bump -> tag -> release) sur toute merge request qui possède le label RELEASE
• écriture du changelog dans un CHANGELOG.md
• bump de la version dans les fichiers packages.json et pyproject.toml
• release en deux étapes :
  • prepare (release-it --dry-run) dans la branche dédiée
  • release réelle dans main une fois la branche fusionnée uniquement
• build de l'image docker uniquement lorsqu'un tag a été associé à un commit dans main, donc quand la branche de release a été fusionnée

Concrètement

Lorsque l'équipe de développement décide qu'il est temps de publier une release :

• on ouvre un ticket avec le label RELEASE
• on ouvre une merge request depuis ce ticket, ce qui lui assigne ce label automatiquement
• un job prepare est automatiquement lancé :
  • clone et build le projet
  • exécute npx release-it --ci --no-npm --gitlab.release --dry-run
  • change la target_branch de la MR (passe de dev à main)
  • écrit le changelog dans la description de la MR histoire d'avoir un aperçu sans aller dans les logs du CI

Voir Draft: Resolve "next release" (!86) pour un exemple réel :)

À partir de là, la MR devient le vecteur de fusion de dev dans main en plus d'être un outil de dry-run de la release. Si rien à signaler, on merge. S'en suit le déclenchement d'un job release dans main, qui exécute npx release-it --ci --no-npm --gitlab.release.

Note : ce schmilblick a nécessité la création d'une clé ssh dédiée à release-it (disponible en variable masquée, avec clé publique disponible en deploy-key), ainsi que d'un access_token dédié à release-it

conventional commit

Ce protocole implique l'utilisation d'une syntaxe conventional commit pour les messages des commits (ou en tout cas des commits de MR lorsque l'option squash commit est activée). Cela permet :

• d'uniformiser la lisibilité de nos contributions
• de générer des changelogs très friendly
• de ne pas se poser la question du numéro de version : le plugin @release-it/conventional-changelog permet d'obtenir un numéro de version cohérent avec le changelog

Seule petit inconvénient, le changelog de la première release sera bizarre car l'utilisation de la syntaxe conventional commit est récente et inégalement utilisée.