Versioning of build artefacts is handled by the Axion-release Gradle plugin, applied in the root
The plugin uses Semantic Versioning, with version numbers in the form
<Majar>.<Minor>.<Patch>, for example:
2.0.13. Version numbers are stored as tags in Git.
Unique version per build
By default, each commit to the repository will trigger a CI GitHub workflow, which will increment the patch version and build the project.
This ensures that each code change is matched by a version number change, making it very easy to trace back a service’s version number to its code.
Setting the next version number
The Version GitHub workflow can be used to manual set the version number the next build will pick up:
- Navigate to the
Actionstab in your GitHub repository.
Set next versionfrom the list of available actions on the left.
- Click the
Run workflow ▾button and either enter the version part to increment, (
Patch), or enter a complete version number to set, e.g.
- Click the Run workflow button below the version info you entered
This will kick off a workflow that sets the new version umber, though you may need to refresh the page to view it. Wait for the workflow to complete before committing any new code.