GitVersion VS semantic-release

I’m not sure about in Bitbucket, but our pipeline has installed GitVersion which ups the build version based on SemVer. https://gitversion.net/docs/ We have a HealthCheck endpoint to return this version.

I know that GitVersion exists, which I think can automatically calculate the version number for me. But it's not entirely clear to me that it will do this. Also it doesn't seem to have a nbgv set-version equivalent that will just create a tag based on the calculated version number.

Kind of like you mention though, I tend to still create a build script using gitversion then just have the GitHub Action kick off the script. I find value in being able to create artifacts on a developer machine so having a simple script to run makes that as painless as possible and when I last looked a year or so ago there wasn't a good way of running GitHub Actions on your development machine.

Self promotion: I made Verlite for this purpose, tho something like GitVersion might be more suitable for your workflow.

We use gitversion to generate semver based on commit height. https://github.com/GitTools/GitVersion

GitHub - GitTools/GitVersion: From git log to SemVer in no time

Unlike Conventional Commits and semantic-release, we let the developer choose the release type (major, minor, patch) and the time at which the package is released.

You could configure your actions to run on new tags (I highly recommend semantic release or similar) on the main branch to publish to GH releases, then on new tags on the prod branch, deploy from the release archive.

Then to release software we rely on semantic-release to implement a solid Semantic Versioning scheme and get a

I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like

feat: support new line chart

fix: update props for new line chart

chore: bump dependency version

What's also cool is there are tools (semantic release) that will then handle automatically publishing and/or creating a new version of your module based on these commits using on the commit type (feat, fix, chore etc) to determine how to bump the version [1].

[0]https://www.conventionalcommits.org/en/v1.0.0/

[1]https://github.com/semantic-release/semantic-release

We're just in the process of implementing automated releases (following semantic versioning concepts) on every push to the main branch of our terraform module using semantic-release . It supports releases, changelogs, and has plugins for GitHub actions and that makes it really easy to integrate into the pipeline if you're keen.

The easiest way to enforce proper semver is by using tools like semantic-release and force major version bump based on keyword detection in the commit log (like "breaking change").

Judging from a quick skim of https://semantic-release.gitbook.io/semantic-release/ and https://github.com/semantic-release/semantic-release it doesn't look like there's any reason you couldn't use it on a go project. You'd have to install node in your dev and CI environments, but otherwise this should work.

Uses semantic-release and commitlint for a streamline CI

semantic-release