[Bug] 5.12.0 does not respect tag in Continuous Deployment mode

[g7ed6e]

Describe the bug
With 5.12.0, in ContinuousDeployment mode, the tag applied to a commit is not took into account and is overriden.

Expected Behavior

If i tag a commit with 1.1.0-preview1 on a master branch i would expect that NuGetVersion and NuGetVersionV2 to be 1.1.0-preview0001 (this is the behavior of GitVersion 5.10.3)

Actual Behavior

• If build is queued by selecting the tag, build is tagged 1.1.0-tags-1-1-0-prev-0001
• If build is queued by selecting the branch master (HEAD is the tagged commit), build is tagged 1.1.0

Possible Fix

GitVersion Documentation is mentionning

Tagging commit
By tagging a commit, GitVersion will use that tag for the version of that commit, then increment the next commit automatically based on the increment rules for that branch (some branches bump patch, some minor).

Steps to Reproduce

Context

Azure DevOps git repo that output nuget packages, GitHub flow. GitVersion used to ship preversion from the master branch.

[HHobeck]

Hi Guillaume. Please provide steps to reproduce!! In advance does this happen in the pre-release 6.0.0-beta.3 as well?

[norigeist]

This bug resembles the closed one in #3351.

Is version 6.0.0-beta.3 supposed to work on a project with target framework 4.7.2? I want to test that version if this issue is solved already, but unfortunately, get this error when building the project. In version 5.12.0, I am still able to build the project.

The command "dotnet --roll-forward Major "C:\<some-path>\packages\GitVersion.MsBuild.6.0.0-beta.3\tools\net6.0/gitversion.dll" "C:\<some-path>\src\TestProject"  -output file -outputfile gitversion.json"

[g7ed6e]

Hi Guillaume. Please provide steps to reproduce!! In advance does this happen in the pre-release 6.0.0-beta.3 as well?

Thanks @HHobeck for quick reply I will send a link to a public repo and build repro asap.

[g7ed6e]

@HHobeck This azure devops repo reproduces the issue: https://dev.azure.com/guillaume-delahaye/_git/GitVersion-Issue3614
There are 2 yaml pipelines. (pipeline-5-10-3 and pipeline-5-12-0).
To see the issue just queue a build with pipeline-5-12-0, selecting either the master branch (you will get a stable build number instead of the tag linked to the HEAD commit), or the tag 1.1.0-preview2 (in that case the build number is a preversion containing the keyword tag).
To see previous behavior queue builds with pipeline-5-10-3

[HHobeck]

Finally the question remains: Is this issue also existing on the pre-release version of git-version? It would be nice to find out the answer.

[HHobeck]

I think it has something to do with the circumstance how the git repository will be checked out. Maybe try the following (see attachment [1]):

steps:
- checkout: self
  clean: true
  fetchDepth: 0

Generally, I don't understand your scenario. Why would you tag a pre-release version on main? The logic how it is implemented is that the pre-release label will be not considered when it's not matching with the branch (see attachment [2]). Thus your expectation to get the version 1.1.0-preview0001 will be never fulfilled even if the git repository will be checked out with branch information (main has an empty tag specification by default).

Attachment [1]:

Attachment [2]:

[igiona]

I think it has something to do with the circumstance how the git repository will be checked out. Maybe try the following (see attachment [1]):

steps:
- checkout: self
  clean: true
  fetchDepth: 0

Generally, I don't understand your scenario. Why would you tag a pre-release version on main? The logic how it is implemented is that the pre-release label will be not considered when it's not matching with the branch (see attachment [2]). Thus your expectation to get the version 1.1.0-preview0001 will be never fulfilled even if the git repository will be checked out with branch information (main has an empty tag specification by default).

Attachment [1]:

Attachment [2]:

If I get you correctly, in order for the pre-release to work I need to create a "-rc" tag in a "rc" branch?
Why would this restriction be needed?

In my workflow I kind of follow the flow suggested by @g7ed6e as well.
Whenever the main is ready for the RC to be created, I simply pre-release it by adding a tag such as "v1.2.3-rc.1".
I only create a release branch if the RC fails the release tests and it requires changes while the main already got new commits.
Otherwise the next rc is simply the next commit on the main, I agree on the fact that this seldemly happen because the main moves on fast with the next release.
But regardless of this detail, hardly my stabilization branch will never match the pre-release tag, I don't see why I should create a "rc" branch in this case?
I would rather create a "release/" branch in which the next release-candidates are consolidated and finally result into the release.

[HHobeck]

If I get you correctly, in order for the pre-release to work I need to create a "-rc" tag in a "rc" branch?
Why would this restriction be needed?

Please see the answer of the following discussion: Using prerelease tag in git tag is removed from version numbers #3663 (reply in thread)

In my workflow I kind of follow the flow suggested by @g7ed6e as well.
Whenever the main is ready for the RC to be created, I simply pre-release it by adding a tag such as "v1.2.3-rc.1".
I only create a release branch if the RC fails the release tests and it requires changes while the main already got new commits.
Otherwise the next rc is simply the next commit on the main, I agree on the fact that this seldemly happen because the main moves on fast with the next release.
But regardless of this detail, hardly my stabilization branch will never match the pre-release tag, I don't see why I should create a "rc" branch in this case?
I would rather create a "release/" branch in which the next release-candidates are consolidated and finally result into the release.

If you want to define a branch with multiple pre-release labels you need to specifiy the label with null value (on branch and root level).

public void EnsurePreReleaseTagLabelWillBeConsideredIfNoLabelIsDefined(long patchNumber)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[HHobeck]

I'm going to close this issue because I think it is the same problem like I have analysed here in the issue:

• [Bug] Build number in Azure DevOps wrong #3351

You need to ensure that the tag matches with the label on the branch with continues delivery mode.