Even so I mostly use Gitlab, I am also active in Github, especially also for the ansible roles which I host in GIthub - just cause everything related to ansible can also be found there.
Since I provide my ansible roles in github, I thought it would be nice to have a proper release workflow with Github Actions. My goal was the following
First you have to place a yaml-file to ./.github/workflow, I name mine release.yaml - the name does not really matter.
trigger a new release by tagging the code
This is straight forward, as I can define this in the pipeline
So the workflow can be triggered as follows
update VERSION-file
Usually the version information - for ansible roles it’s the VERSION-file should be updated before you create a release and before you import the role into ansible-galaxy. Thus I want that automated and using the same version as from the tagging operation. Thus I store the release version in a variable and use it later
Update the changelog
Instead of manually creating and committing the changelog, I want this automated. I looked into different implementations and finally decided to use auto-changelog which works quite nice.
So I have to first install the npm package
Then I can use it in the pipeline to create the CHANGELOG.md. I only want commits which contains features and bug fixes, not changes of metadata or ci. Thus I usually add something like [meta] or [ci] as prefix of the commit message to distinct the type of commit. Thus I can ignore such commit messages quite easy
Committing changes
As there are changes in the VERSION and CHANGELOG.md I will commit this changes and also update the tag so it points to this commit. For that purpose I have to create a release-branch as otherwise committing changes will simply be lost.
I found the git-auto-commit-action to commits files which have been changed during a Workflow run and pushes the commit back to GitHub:
create a release
To create a proper release incl. release notes is easily done with create-release action. I dynamically create the RELEASENOTES.md which provides the content for the particular release. The difference to the CHANGELOG.md is that it only contains the diff between the previous and the current tag, plus the file will not be committed. I use the same auto-changelog from above.
Once I have the RELEASENOTES.md I can create the release using the $RELEASE_VERSION and body_path: ./RELEASENOTES.md:
As there is a separate release branch I will have to merge it back to master-branch. I guess that’s not bad as it let me review the changes.
Bring it all together
At final the file release.yml looks something like this
The workflow covers the basic, straight forward release process and avoids manual steps where possible. There is for sure things to improve, but for now it does it’s job very well.