Hi all,
the ones of you, who joined the last office hours already know, that I created a
playground repository to play with the
release-please-action.
I started playing with release please, because of personal experience and learnings from our release and quality gate phases in Tractus-X.
We do have different approaches, when it comes to releases and we also still have teams, without active committers as team members.
I invite you all to have a look at that playground repo (https://github.com/catenax-ng/release-automation-playground) and invite the consortia
team to directly work on it.
Take your chance and create some example commits / PRs to see how that works and form your own opinion, if that workflow could improve your quality of live in eclipse-tractusx. (You can ping the System Team in case you
have questions)
Short recap on what the release-please action is doing:
- It is relying on conventional commits in your git history
- Every time you push commits, the release-please-action prepares a “release PR”,
- It will maintain a CHANGELOG.md with your messages from the conventional commits
- It creates separate sections for fixes / features etc. automatically
- It includes “customer facing” commits. chore: or refactor: are ignored for example
- It automatically increments the semantic version correctly, based on your conventional commits
- You can actively decide, when you want to create a release, by merging the already prepared PR
- The release-please-action will then create the correct git tag for your new version
- The release-please-action will create a GitHub release stating the changes since last release
- You can react on outputs of release-please to further automate the release (see example. Compiling .md docs to PDF and attach to GitHub release as artifact
https://github.com/catenax-ng/release-automation-playground/blob/main/.github/workflows/release.yaml#L24-L36)
Observations from recent experiments:
- Release please recommends squash merge
- We already know, that we have to be careful with this in regards to copyright headers and so on
- Squashing will lead to only one entry in the CHANGELOG.md, regardless of the number of conventional commits in the originating branch
- Potential loss of info in CHANGELOG can be mitigated by creating small PRs for every single fix or feature. This is anyway a good practice
- The CHANGELOG format is slightly different to
https://keepachangelog.com/en/1.1.0/, which we currently follow. But only in formatting, not in content or semantics
Looking forward to your feedback and test-commits!
Best regards
Sebastian
Mit freundlichen Grüßen / Kind regards
Sebastian Bezold
Software Engineer
Mercedes-Benz Tech Innovation GmbH
(ehemals/formerly Daimler TSS GmbH)
Wilhelm-Runge-Straße 11
89081 Ulm/Germany
Sebastian.Bezold@xxxxxxxxxxxxxxxxx
www.mercedes-benz-techinnovation.com
![signature_133997463](jpgHBXJ0fJydy.jpg)
Mercedes-Benz Tech Innovation GmbH
Sitz und Registergericht/Domicile and Register Court: Ulm, HRB-Nr./Commercial Register No.: 3844
Geschäftsführung/Management:
Daniel Geisel (Vorsitzender/Chairperson), Isabelle Krautwald