Automating GitHub releases with Release Please

I was recently introduced to a GitHub Action called release-please which I’ve enjoyed using and seeing in action, so naturally to get a better understanding of it I’m writing this short blog post! Hopefully, someone finds it useful.

So a quick overview of Release Please and why you might need it in your life.

This really does improve the workflow from my previous write up on GitOps with GitHub Actions where to trigger my GitHub Action to build and push my Docker container image I created a release which had a sever tag, and this worked fine.

But I’m manually created that release, couldn’t there be a better way to release without me having to type up everything about what happened to make that release, like an automated changelog? This is where automated releases with Release Please come in!

I’ve taken the same very simple Python application that is in a Docker container it builds and gets pushed to my personal private Docker hub repo.

I have also added another GitHub Action Workflow:

on:
  push:
    branches:
      - main

permissions:
  contents: write
  pull-requests: write

name: release-please
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          token: ${{ secrets.MY_RELEASE_PLEASE_DEMO_TOKEN }}
          release-type: simple

.github/workflows/release-please.yaml In its simplest, tells my repo on a Push top the main branch create a release PR, there are some caveats here. I have also created a GitHub Token and added it as a repo secret MY_RELEASE_PLEASE_DEMO_TOKEN so it can make changes to my repo.

So how does Release Please know what or when to create a release?! Essentially by using conventional commits anything that is deemed a releasable unit is a commit to the branch with one of the following prefixes: "feat", "fix", and "deps".

So my PR which I have reviewed and merged into the main branch, contained a “feature” or “feat” prefixed commit as seen by Release Please. Release Please then creates a PR based on what we’ve told it is a releasable feature, in this case, a “feat” or feature.

What’s really neat is it also keeps a running change log, giving you lots of handy info about what’s being brought into the release and leaves a nice audit trail of your releases….. Automatically!

Even if the Release Please PR is open and you publish more commits to the branch it will edit the Pr and pick them up.

The release-please Action has triggered and is now running to create the release, my new Release Action then triggers because it is configured to build the docker image when a new tag release has been created, which has been taken care of by Release Please!

I’ve got a little more tinkering to get the deployment part (creating the PR to my environment-infrastructure repo that Argo CD deploys from…) but hopefully, you get the picture that this is a great tool to automate your releases!

Conventional Commits

Woah Woah Woah?! So you might be thinking “You’ve gone from this is just easy releases to now conventional commits?! What’s this all about?!”

I know, it feels like more things to learn for the thing you were trying to learn, but conventional commits wraps this all up and to make it work, it essentially ensures you follow a preferred standard and pattern of commit messages, we’ve all been there and wished our colleagues or past selves took more time to create a commit message “HerpDerp“ may have been applicable at the time but future you will thank you for conventional commits, you can read up about them here Its also how Release Please knows what you want to release and what doesn’t actually need a release (Changes to README.md’s ama right?!)

There is a VSCode IDE plugin in for it so it just works or even better, like me you don’t like too much or any M$ products it also works with VSCodium (A nice non M$ non steal all your data alternative IDE).

Also like me, you don’t like to use Git using the IDE and prefer the terminal CLI there is also Commitizen which helps with keeping your conventional commits….. well, conventional!

This was introduced to me by a colleague and I have just been having fun learning a bit more about it and finding a way it can work with my existing development.

Whats next? Or is that it?

This is a pretty simplified implementation of Release Please, which shows how easy it is to get up and running.

You can be more customised and granular with the configuration of Release Please which is something I’m planning on tinkering with and getting working with the deployment repo I have.

For the next part, I am looking to improve this by using a release-please-config.json to manage my own versioning and package contents.

Hopefully for anyone getting started, this will be helpful! If you have any thoughts or comments or something I have missed or should even try differently, please hit me up on the comments. I’m always happy to keep learning and hear different opinions and methods :-)