[tractusx-dev] Proposal: GitHub release automation via Release Please Ac

[<sebastian.bezold@xxxxxxxxxxxxxxxxx>]

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

 

      

 

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

 

If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.