Semantic-Release et le versioning automatique

Salon des Développeurs Suggestions dev
1

Bonjour,

Je continue sur le sujet des automatisations à l’aide du Workflow Github, aujourd’hui il s’agit de gérer à la fois le ChangeLog, les numéros de version, et même les releases, en automatique et sur plusieurs branches.

Présentation

Les plugins n’ont pas forcément de numéro de version, seulement une date, mais on pourrait tout à fait ajouter dans le info.json un numéro de version qui soit maintenu automatiquement. Il sera éventuellement utile un jour… Idem pour le changelog, le principe de Semantic-Release est justement de construire le changelog automatiquement. Ainsi, après chaque commit / push, un workflow s’exécute pour rajouter un 2e commit (par le semantic-release-bot) qui ressemble à ceci:

Ceci est possible sur la branche master (enfin, v4-stable, ou la branche principale) mais aussi sur une ou plusieurs branches de pre-release (develop, beta …). Par exemple j’ai une branche dev sur laquelle le bot semantic-release met à jour le fichier changelog_beta.md.

Enfin, le plugin permet aussi de calculer automatiquement le prochain numéro de version, avant de le modifier dans le changelog d’une part, et dans le fichier info.json d’autre part. Donc il n’y a vraiment aucune intervention de ma part pour tout cela. Le plugin va même créer la release, ce qui n’a à priori aucun intérêt pour nous pour des plugins Jeedom (mais pour le core, peut être…?)

Pourquoi ça marche ?

Pour arriver à ce résultat, il n’y a pas de magie (hélas) il faut donc se contraindre à une convention stricte sur les messages de commit. La Gestion des Versions comme on le fait déjà (un numéro de version sur 3 chiffres : major.minor.patch) peut être gérée en suivant la Convention des Commit que je résumerais ainsi:

Message pour un patch:

fix: Je corrige un bug

Message pour une nouvelle fonctionnalité:

feat: nouvelle fonctionalité d’envoi de messages

Message pour une nouvelle version majeure: il faut ajouter le mot-clé BREAKING CHANGE

feat: allow provided config object to extend other configs

BREAKING CHANGE: extends key in config file is now used for extending other config files

D’une manière générale, un commit doit donc respecter ce format: les lignes vides sont importantes pour séparer body / footer, mais tout ceci est optionnel. Seul le type ( = fix feat chore doc build test perf …) et la description sont obligatoire. Et seul fix et feat participent à la numérotation automatique.

type[optional scope]: description
(ligne vide)
[optional body]
(ligne vide)
[optional footer(s)]

Cette convension des commits est bien détaillée ici et je vous invite à la parcourir :

Comment ça marche ?

L’implémentation de Semantic-Release passe évidemment par un fichier yml dans le /.github/workflow, et j’en ai fait 2 : l’un pour la branche master et l’autre pour les pre-release, branche dev chez moi.

La particularité est que j’utilise un plugin spécifique pour personnaliser les noms de fichiers de changelog docs/fr_FR/changelog.md ou docs/fr_FR/changelog_beta.md et aussi pour modifier le numéro de version pluginVersion dans le fichier plugin_info/info.json. Toutes ces options sont fixées dans ce dépôt ci-dessous (c’est du NodeJS) mais vous n’avez pas à vous en soucier, il suffit de l’utiliser dans le yaml avec ce paramètre: --package=jeedom-semrel-plugin-config@1pour la branche principale (la v1 du package) ou bien --package=jeedom-semrel-plugin-config@beta pour une branche de dev / prerelease.

En conclusion et pour finir, bien que la gestion des commits peut paraitre un peu fastidieuse, on peut tout à fait faire du dev sur une branche autre que master / beta, accumuler les commit sans norme comme avant, et puis au moment où ça marche et où on merge, dans l’une des branches master / dev, on squash et on écrit le commit qui va bien :slight_smile:

J’attends vos retours remarques et critiques pour développer un peu plus.

9 « J'aime »
2

Hello je vois que ma proposition soulève l’enthousiasme c’est cool :smiley:

Cette convention de commit git répond aussi à cette problématique:

En effet, 1 commit préfixé doc: ... ne génère pas une nouvelle version du plugin, donc pas de nouvelle publication.

Je me proposais d’ajouter les workflow dans le plugin template, bonne idée ou bien ?

3

Hello,

Super travail tu trouvera sur le github de jeedom un repo nommé workflows. Que je suis en train de monter pour que celui-ci soit utilisé par tout les plugins.

Je travail encore sur le coté test pr etc.

Il est possible que j’utilise ton travail !
Si ça te vas ? ^^

4

Hello,

J’ai oublié de préciser qu’il faut donner au workflow en question les write permissions pour créer le commit de semantic-release

image
image807×311 23.5 KB

à priori c’est le cas aussi pour le prettier puisque j’ai eu cette erreur chez moi:

Pushing changes with Git
  remote: Permission to pifou25/plugin-template.git denied to github-actions[bot].
  fatal: unable to access 'https://github.com/pifou25/plugin-template/': The requested URL returned error: 403
  Error: Command failed: git push
5

Bonjour,

J’ai fait une PR sur le plugin-template pour ajouter le Semantic-Release au repo !

Sur la PR cette erreur:

image
image1038×133 11.4 KB

C’est parce qu’il y a 2 autres commit avec le mien, qui ne respectent pas la convention de commit, donc le check est KO mais ce n’est pas bloquant pour merger.
Si je fais la même PR sur master, c’est vert car il n’y a qu’1 seul commit - le mien - et il est valide. Je peux refaire la PR sur master si vous préférez :slight_smile:

Du coup, si certains sont motivé je propose de faire la même sur vos repo / plugins, me contacter :slight_smile:
Globalement il suffit de « cherry-pick » ce commit sur votre propre plugin, et, comme mentionné ci-dessus, paramétrer le workflow pour avoir la permission « write ».

Un exemple d’application sur mon plugin, on peut voir le commit du bot ‹ semantic-release › et les modifications qu’il a faite.

… Prochaine étape je vous propose la même méthode sur le jeedom-core :stuck_out_tongue:

2 « J'aime »