How to set a simple pipeline, w/o having to tag every release?

[TsengSR]

GitVersion is driving me to commit suicide trying to set up an pipeline, that can build NuGet artefacts and push them to Nuget with unique versions without having to tag and manually trigger the pipeline every time.

What I want is a simple pipeline and GitVersion configuration that with each merge/commit creates a unique version that can be used with nuget.org or azure devops artefact feeds.

For example

dev:

• 0.1.0-beta.1
• 0.1.0-beta.2

PRs:

• 0.1.0-PullRequest.3
• 0.1.0-PullRequest.4

release/0.1.0

• 0.1.0-rc.1
• 0.1.0-rc.2 (after next commit or merge; 0.1.0-rc.1+1 causes nuget push to fail due to same version semantics)
  release/0.1.0 merge in main
• 0.1.0 (not 0.1.0-10)

dev

• 0.2.0-beta.1

hotfix on 0.1.0

• 0.1.1-beta.1

etc. manually tagging is out of question, as in early development there will be a lot of beta and rc releases and it's very error-prone. I spent like 2 weeks already trying to get it to work.

Also a side question: Why does the verison bump work with release/0.1.0 but not with release/0.1? This used to work with versions prior to 6.x.

workflow: GitFlow/v1
branches:
  develop:
    label: beta
  release:
    label: rc
# Ignore this one, it was my attempt to try to build the releases from tag trigger 
  tags:
    regex: '^v'
    is-release-branch: true
    label: ''
  bugfix:
    label: '{BranchName}'
    increment: Inherit
    regex: ^bugfix(es)?[/-](?<BranchName>.+)
    source-branches:
    - main
    - release
    - support

I tried to skip the pushing during the PR/branch build and have it trigger when a new tag is created, but that worked even worse as the tag gets checked out in detached mode and completely messes up the versioning (it attempts to use the escaped SourceBranchName turning v0.1.0-rc.1 into 0.1.0-rc-1.1. I remember using GitVersion 7-8 years ago and it worked out of the box the way I wanted it, but now I can't get it to work no matter what.

As for why, well I have 2 dozen of .NET libraries and need to have the beta and rc builds available in nuget so I can test it in the main application and only promote a library to stable when its been tested enough and want to avoid having like 400 versions of a package in a nuget feed (which is the case in previous project) which makes it very hard to figure out which libs are stable and which not, when there's no proper pre-release tags (the old projects used mainline versioning, so they bumped patch version with every commit)

[HHobeck]

Please see the GitFlow Examples which illustrates the branching and merging strategies sufficient for most use cases. The build in template for GitFlow/v1 can be found here.

Generally if you want to always have a new semantic version (as pre-release version) for each commit you just need to specify the deployment mode to ContinuousDelivery for the specific branch.

The documentation says:

Manual Deployment

Having not the necessity to deploy the build artifacts on every commit is an indication of using the Manual Deployment mode. This mode can be used to remain on the same pre-released version until it has been deployed dedicatedly.

vs.

Continuous Delivery

Continuous Delivery is the process of checking into a branch, running all the tests and if everything goes green it is automatically pushed to a testing system.

A good case for Continuous Delivery is when using Octopus deploy, as you cannot publish the same version of a package into the same feed.

To your question:

Also a side question: Why does the version bump work with release/0.1.0 but not with release/0.1? This used to work with versions prior to 6.x.

This is because in GitFlow/v1 semantic-version-format is set to Strict. In the breaking change documentation you will find the following:

There is a new configuration parameter semantic-version-format with default of Strict. The behavior of Strict is, that every possible non-semver version e.g. 1.2.3.4 is ignored when trying to calculate the next version. So, if you have three-part and four-part version numbers mixed, it will compute the next version on basis of the last found three-part version number, ignoring all four-part numbers. This is different compared to v5 where per default it was a Loose comparison.

Happy branching!