Go Release Manager

Le problème

Décider la prochaine version se fait souvent à la main : quelqu'un lit les commits, choisit entre patch, minor et major et crée le tag. C'est lent, cela dépend de la mémoire et l'erreur est facile, surtout avec les pré-releases et les changements incompatibles.

Des outils comme semantic-release résolvent le problème, mais apportent Node.js, des plugins et de la configuration à des projets qui n'en utilisent pas.

La solution

Un binaire unique, sans dépendances, qui lit les commits depuis la dernière version stable, applique les Conventional Commits et calcule le prochain tag SemVer. L'outil fait une seule chose : le build, les notes et la publication de la release restent du ressort de GoReleaser.

• La commande next n'affiche que la version, pour les scripts ; la sortie JSON donne le résultat complet.
• La simulation (--dry-run) montre tout sans rien écrire ni demander d'identifiants.
• Des pré-releases par canal (beta, rc) avec un compteur continu, une version imposée quand le plan l'exige et un tag sur un commit précis.
• Une GitHub Action prête à l'emploi, qui télécharge le binaire de la release et vérifie sa somme de contrôle avant de s'exécuter.
• --explain liste les commits qui ont décidé l'incrément et la règle de chacun, pour que personne n'ait à deviner pourquoi la version est passée en major.

Changements incompatibles et squash merges

Après la publication, un lecteur a demandé ce qui se passe dans un squash merge, où seul le message final du commit décide la version. Si l'avis BREAKING CHANGE n'est que dans la description de la PR ou dans un commit intermédiaire, et que le titre n'a pas de "!", la release sort en minor alors qu'elle devrait être major, et les utilisateurs mettent à jour sans savoir que quelque chose a cassé.

La v1.3.0 comble cette faille par couches, toutes avec la même règle de détection que le calcul de version :

• La commande check-pr refuse la PR quand une rupture annoncée quelque part manque dans le titre, et propose le bon titre ; elle signale aussi un pied de page mal placé et un "BREAKING CHANGES" mal écrit.
• Une Action check-pr pour la CI, qui lit le titre et la description dans le fichier de l'événement, et non dans le script, pour qu'un titre malveillant ne puisse pas injecter de code.
• Un filet de sécurité après le merge, qui compare le commit arrivé sur main avec sa PR et ouvre une issue si la rupture s'est perdue.
• Un guide de bonnes pratiques, en portugais et en anglais, sur ce que GitHub garde selon le réglage du squash et sur la façon d'écrire la PR.

Comment la qualité est garantie

Le projet suit le même processus que j'utilise au travail :

• Développement guidé par les spécifications : chaque règle de version a des critères d'acceptation, et chaque critère renvoie au test qui le prouve.
• Tests unitaires et de bout en bout, avec 97 % de couverture du code ; la CI exige au moins 80 %.
• CI sur chaque pull request : lint, tests avec détection des accès concurrents, build, commandes du README, l'Action exécutée sous Linux, macOS et Windows et check-pr lui-même qui vérifie le titre.
• Releases automatisées : l'outil calcule sa propre version, et GoReleaser publie des binaires pour cinq plateformes avec des sommes SHA-256.
• Une branche et une pull request par tâche, avec Conventional Commits et un CHANGELOG.

Choix techniques

• La base est toujours le plus haut tag stable atteignable : une pré-release ne devient jamais la base par erreur.
• En version 0.x, un changement incompatible augmente la minor, comme le prévoit SemVer.
• Les diagnostics vont sur stderr et le résultat sur stdout : les scripts lisent la sortie sans rien filtrer.
• L'outil parle anglais, et la documentation est un guide complet en portugais et en anglais.

Résultat

L'outil calcule les versions de sdd-kit, mon kit de développement guidé par les spécifications, à chaque clôture de phase. Lors de la revue avant la mise en production, de nouveaux tests ont fait passer la couverture de tout le code de 7,9 % à 97,1 %, et un défaut du --version du binaire publié a été trouvé et corrigé avant la diffusion.

Limites

L'usage réel se limite encore à sdd-kit et à mes projets ; il manque la validation par d'autres équipes. check-pr ne détecte que les ruptures déclarées (avec "!" ou BREAKING CHANGE) : une rupture que personne n'a annoncée demanderait de comparer l'API publique entre versions. Aucune image Docker n'est publiée, et volontairement l'outil ne rédige pas le changelog et ne publie pas la release lui-même.