Super, merci pour les liens, j’en retiens donc essentiellement « the GitLab Changelog API » Changelogs | GitLab, ça permet de se passer de la lecture de la partie « chatbot », « blockchain » et « capital venture » du tuto gitlab, qui reste intéressant si on passe ces références vendeuses ^^
En résumé, ça permet de générer le changelog à partir d’un « trailer » (un marqueur spécifique dans le commit, comme pour les commits conventionnels) posé dans le log d’un commit, exemple « Changelog: feature ».
To be included in a changelog, a commit must contain a specific Git trailer.
Donc un commit qui ne contient pas de marqueur ne sera pas listé dans le changelog. Ainsi, sur une PR qui contient plusieurs commits, on peut définir son changelog uniquement dans le commit « révélateur » de la PR.
On peut aussi personnaliser les catégories utilisé dans les marqueurs pour les ligner sur celles qu’on utilisent avec les commits conventionnels cf Changelogs | GitLab
Et aussi personnaliser le format du changelog généré, bref ça semble vraiment une piste intéressante, car ça nous évitera les conflits sur les modifications des fichiers changelog lors des reports dans les branches stables. Et, si jamais on doit reprendre le changelog foireux d’une PR avant merge, il suffit d’un git commit --amend.
Le seul point qui me semble moins pratique que l’usage actuel est que je ne pense pas qu’on puisse revenir sur une entrée de changelog une fois le commit mergé dans une branche (on ne fais pas de commit amend et force push dans master ou une branche stable).
À noter, dans le tuto les gens utilisent des commits de merge sur chaque PR, et donc c’est avec ce commit que le changelog est posé, or on n’utilise pas les commits de merge chez nous.
Je suis bien intéressé pour tester le bouzin sur la partie changelog, je tente de trouver un temps pour ça dans un repo perso dans les jours à venir (si personne ne s’y colle avant).
, beaucoup de réponses possibles.
