Cela fait un moment que je voulais tester release-please dans le but de me faciliter la vie avec la génération de changelog et de tags sur des projets.
Je vais utiliser un de mes projets. Certes pour moins de 1000 lignes de code cela va être surfait, mais il faut bien s'amuser.
Prérequis
- Connaître les conventional commits
- Connaître les github actions
Mise en place de release please
Tout d'abord on créé le fichier .github/workflows/release-please.yml
qui va contenir notre github action.
---
name: Release-Please
on:
push:
branches:
- main
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: google-github-actions/release-please-action@v3
with:
release-type: go
default-branch: main
Une fois en place, une pull request est ouverte par le github-actions bot:
L'action remplie les fichiers CHANGELOG.md
et .release-please-manifest.json
avec les différentes informations trouvées dans les messages de commits. La version est incrémentée en fonction des conventional commits. Ce comportement est inhérent au fait que j'utilise la clé release-type
positionné à go
(voir les autres types).
Et voilà on commence à génèrer des releases github de façon programmatique.
Après le merge notre première release est créée
Release et intégration continue
Avec cette version lors de la création de la release et du tag associé, il n'y aura pas de github action qui sera déclenchée (plus de lecture par ici sur le GITHUB_TOKEN
).
Dans mon cas, lors d'une nouvelle release je souhaite qu'un conteneur soit construit. J'injecte donc un token personnel via la directive token
de l'action.
Note: au 20/02/2023 il faut utiliser un token personnel (pat), on ne peut pas utiliser les tokens avec des droits fins.
...
steps:
- uses: google-github-actions/release-please-action@v3
with:
release-type: go
default-branch: main
token: ${{ secrets.RELEASE_PLEASE }}
...
Pour avoir un token valide il faut les droits suivants
Cela me permet donc d'avoir la github action suivante qui se déclenche sur génération de tag github:
---
name: Docker
on:
push:
tags:
- '*'
jobs:
build:
runs-on: ubuntu-latest
steps:
# build stuff
...
Fashion formating
On peut par la suite via la directive changelog-types
ajouter du shiny sur nos releases:
...
steps:
- uses: google-github-actions/release-please-action@v3
with:
...
changelog-types: |
[
{"type":"feat","section":"🚀 Features","hidden":false},
{"type":"change","section":"🚀 Features","hidden":false},
{"type":"deprecate","section":"⚠️ Changes","hidden":false},
{"type":"remove","section":"⚠️ Changes","hidden":false},
{"type":"fix","section":"🐞 Bug Fixes","hidden":false},
{"type":"revert","section":"🐞 Bug Fixes","hidden":false},
{"type":"security","section":"🐞 Bug Fixes","hidden":false},
{"type":"perf","section":"✨ Polish","hidden":false},
{"type":"refactor","section":"✨ Polish","hidden":false},
{"type":"style","section":"✨ Polish","hidden":false},
{"type":"build","section":"🧰 Other","hidden":false},
{"type":"chore","section":"🧰 Other","hidden":false},
{"type":"deps","section":"🧰 Other","hidden":true},
{"type":"ci","section":"🧰 Other","hidden":true},
{"type":"test","section":"🧪 Tests","hidden":false},
{"type":"docs","section":"📚 Documentation","hidden":false}
]
Le rendu est le suivant
Conclusion
Et voilà, on a des releases et des conteneurs automatiques, derrière cela s'intègre dans des mises à jour via dependabot ou renovate ou dans l'image updater de fluxcd.
Notes
Tous les type
commits ne déclenchent pas une release, par exemple si vous faite un commit de type refactor
, l'action n'ouvrira pas de pull request contrairement à feat
et fix
(plus d'informations)
Credits
- Cover image link
Top comments (0)