HashiCorp Nomad and Vault: Dynamic Secrets
In a cloud-native environment, secrets management is a critical aspect of security. HashiCorp Vault is a popular tool for managing secrets and protecting
The connection between human emotions and the next version number of a project can lead to unwanted outcomes.
As developers, we are often faced with the usually very laborious and tedious task of writing changelogs with tags and dedicated version names that have been tagged in a code repository. Therefore, it is nice if we can automate such tasks.
This blog post is about Semantic Versioning and how using GitHub Actions can automate the process of writing changelogs.
This blog post has a close connection to a previous post with the title “Changelog Automation within Gitlab” and presents an example implementation of Semantic Versioning within GitHub.
The use of Semantic Versioning allows GitHub to automatically create changelogs based on commit messages. Of course this means that commit messages need to follow a certain format.
In this example we are using the following GitHub Action to create changelogs.
1name: Releases
2on:
3 push:
4 branches:
5 - main
6 pull_request:
7 branches:
8 - main
9
10jobs:
11 changelog:
12 runs-on: ubuntu-latest
13
14 steps:
15 - uses: actions/checkout@v2
16
17 - name: conventional Changelog Action
18 id: changelog
19 uses: TriPSs/conventional-changelog-action@v3.7.1
20 with:
21 github-token: ${{ secrets.GITHUB_TOKEN }}
22 # skip-version-file: 'true'
23
24 - name: create release
25 uses: actions/create-release@v1
26 if: ${{ steps.changelog.outputs.skipped == 'false' }}
27 env:
28 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
29 with:
30 tag_name: ${{ steps.changelog.outputs.tag }}
31 release_name: ${{ steps.changelog.outputs.tag }}
32 body: ${{ steps.changelog.outputs.clean_changelog }}
Of course, it is possible to add a build phase to this pipeline that - for example, creates and pushes a new Docker image and writes the latest tag of the Docker image to the changelog.
When this pipeline runs successfully, it automatically creates a CHANGELOG.md and a package.json file if they do not already exist.
The automatic creation of files can be controlled by providing further parameters in the GitHub Action workflow. With these parameters it is possible, for example, to skip the creation of the package.json file by using skip-version-file: 'true'
. For further details please refer to the official documentation.
If the implementation occurs after a tag with a version number has been added, you must manually edit the package.json file to match that version number, should the file exist.
If there is no Git tag associated with a previous version of the project, the first version will be 0.1.0, regardless of what the change is (fix, feat, BREAKING CHANGE).
FIX: (e.g. v0.1.0 → v0.1.1)
1git commit -m "fix: message"
FEAT: (e.g. v0.1.1 → v0.2.0)
1git commit -m "feat: message"
BREAKING CHANGE: (e.g. v0.2.0 → v1.0.0)
1git commit -m "feat: message" -m "BREAKING CHANGE: message"
You are interested in our courses or you simply have a question that needs answering? You can contact us at anytime! We will do our best to answer all your questions.
Contact us