Go SemVer Release
Go program designed to automate versioning of Git repository by analyzing their formatted commit history and tagging them with the right semver number. This program can be used directly via its CLI or its corresponding GitHub Action.
Motivations
Handling a Git repository versions can be done seamlessly using well-thought convention such as SemVer so that consumers know when a non-retro-compatible change is introduced in your API. Building on that, versioning automation is achieved using formated commits following the Conventional Commit convention.
Because versioning should not be a bottleneck of any kind in your CI/CD workflow, the Docker image merely weight 7Mb and the Go program inside will compute your semver in seconds, no matter the size of your commit history.
This tool aims to integrate semantic versioning automation in such a way that, all you have to do is:
-
Choose a release branch (e.g. main
, release
)
-
Take care to format commits on that branch by following the Conventional Commit convention, which many IDEs plugins offers to do seamlessly (e.g. VSCode, IntelliJ)
Install
If Go is installed on your machine, you can install from source using go install
:
$ go install github.com/s0ders/go-semver-release
$ go-semver-release --help
For cross-platform compatibility, you can use the generated Docker image:
$ docker pull soders/go-semver-release
$ docker run --rm soders/go-semver-release --help
Prerequisites
There are only a few prerequisites for using this tool and getting the benefits it brings :
- The Git repository commits must follow the Conventional Commit convention, as it is what is used to compute the semantic version.
- The repository passed to the program (or action) must already be initialized (i.e. Git
HEAD
does not point to nothing)
Usage
You must pass the Git URL of the repository to target using the --url
flag:
$ go-semver-release --url [GIT URL]
Because the program needs to push tag to the remote, it must authenticate itself using a personal access token passed with --token
:
$ go-semver-release --url ... --token [ACCESS TOKEN]
The release branch on which the commits are fetched is specified using --branch
:
$ go-semver-release --url ... --token ... --branch release
Custom release rules are passed to the program using the --rules
:
$ go-semver-release --url ... --token ... --rules [PATH TO RULES]
The program supports a dry-run mode that will only compute the next semantic version, if any, and will stop here without pushing any tag to the remote, dry-run is false
by default:
$ go-semver-release --url ... --token ... --dry-run true
A custom prefix can be added to the tag name pushed to the remote, by default the tag name correspond to the SemVer (e.g. 1.2.3
) but you might want to use some prefix like v
using --tag-prefix
:
$ go-semver-release --url ... --token ... --tag-prefix v
Note: You can change your tag prefix during the lifetime of your repository (e.g. going from none to v
) and this will not affect your semver tags history, meaning that the program will still be able to recognize semver tags made with your old-prefixes, if any. There are no limitation to how many time you can change your tag prefix during the lifetime of your repository.
GitHub Actions
The action takes the same parameters as those defined in the usage section. Note that the --dry-run
needs to be passed as a string inside your YAML workflow due to how Github Actions works.
Outputs
The action generate a two outputs
SEMVER
, the computed semver or the current one if no new were computed, prefixed with the given tag-prefix
if any;
NEW_RELEASE
, whether a new semver was computed or not.
Example Workflow
Bellow is an example of this action inside a GitHub Actions pipeline.
jobs:
go-semver-release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Semver Release
uses: s0ders/go-semver-release@v1.3.0
with:
repository-url: 'https://github.com/path/to/your/repo.git'
tag-prefix: 'v'
branch: 'release'
dry-run: 'false'
token: ${{ secrets.ACCESS_TOKEN }}
Release Rules
Release rules define which commit type will trigger a release, and what type of release (i.e. major, minor, patch). By default, the program applies the following release rules:
{
"releaseRules": [
{"type": "feat", "release": "minor"},
{"type": "perf", "release": "minor"},
{"type": "fix", "release": "patch"}
]
}
You can define custom release rules to suit your needs using a JSON file and by passing it to the program as bellow. Be careful with release rules though, especially major ones, as their misuse might can easily make you loose the benefits of using a semantic version number.
{
"releaseRules": [
{"type": "perf", "release": "minor"},
{"type": "ci", "release": "patch"},
{"type": "fix", "release": "patch"}
]
}
The following type
are supported for release rules: build
, chore
, ci
, docs
, feat
, fix
, perf
, refactor
, revert
, style
, test
.
The following release
types are supported for release rules: major
, minor
, patch
.