Automate semver in ConcourseCI - semantic-versioning

Question

I have a ConcourseCI pipeline that automatically increments my version number using this resource type: https://github.com/concourse/semver-resource
My resource declaration looks like this:
- name: version
type: semver
source:
driver: git
initial_version: 0.0.1
uri: {{version-repo-uri}}
branch: {{version-repo-branch}}
file: {{version-file}}
private_key: {{git-key}}
And my job looks like this:
- name: increment-version
plan:
- get: {{git-repo-name}}
trigger: true
- get: version
params: {bump: patch}
- put: version
params: {file: version/version}
So as you can see, right now I'm always bumping PATCH version. However, I'd like an easy and preferably automated way for the pipeline to increment MAJOR, MINOR, PATCH, or RC version depending on the circumstances.
Is there a git hook or something similar that will know when to bump what? Any implementation best practices when automating semver into a pipeline? Any other Concourse resource-type I should be using instead? Or is this something we should definitely leave for a human to decide? And in that case, how to easily integrate that "manual" step into a CD pipeline?
The closest thing I can think of is having a version file in my project (committed to github) with the intended version, which will set MAJOR, MINOR, PATCH numbers. The pipeline picks ups that file, uses it as a base somehow, and only increments RC numbers, but this feels incredibly error prone.
To be clear, I'm not asking how to version releases in theory, and the meanings of what major, minor, or patch are. I'm asking in practice how to implement those recommendations listed on https://semver.org/.

Answer 1

My solution to this problem is to tag the commits, and a script which reads the Git commit message and steps the version based on the content:
If a version tag exist on the current commit: always step PATCH.
Else:
List all commits until the previous tag.
If any message contains "step: major" then step MAJOR
Else if all messages contain "step: patch" or "step: micro" then step PATCH
Else step MINOR
This means that if the committer does not state anything in the message, then the change is assumed to be a functional change.
Tag and push the commit before the built artifact is distributed. Otherwise the next build could produce an already existing version.
Just modify the logic as needed for your use cases.