[Bug] Tag not used as version when running in GitLab Pipeline (Mainline)

[J0F3]

Describe the bug
I am experience a very strange behavior while using GitVersion with GitLab. When I tag the last commit of the repo GitVersion always takes the version of the tag and bumps patch version to 1. E.g when the Git Tag is '2.0.0' the version calculated by GitVersion is then '2.0.1'

Not sure what exactly happens here but when I clone the repo locally and run GitVersion locally it works as expected and use the tag as the version.
I also already disabled the git cloning in GitLab an configured dynamic repositories like it is done in this example:
https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/-/blob/develop/gitversion-ci-cd-plugin-extension.gitlab-ci.yml
But the behavior did not change.

So while I am not sure if this is really a bug I am still apricate any inputs how to fix that.

Thx!

Expected Behavior

When the last commit in the repos is tagged with e.g. '2.0.0' the calculated version of GitVersion is '2.0.0'.

Actual Behavior

Instead '2.0.0' the calculated version is '2.0.1'. (Always one patch version higher than what in the git tag is set).

Possible Fix

?

Steps to Reproduce

1. Simple Repository with some commits
2. Add a Tag '2.0.0' to the last commit in the Repo
3. GitLab Pipeline runs and executes:
   dotnet-gitversion -overrideconfig mode=Mainline -output buildserver -url $CI_REPOSITORY_URL -u gitlab-ci-token -p $CI_JOB_TOKEN -b $CI_COMMIT_REF_NAME -c $CI_COMMIT_SHA -dynamicRepoLocation $CI_PROJECT_DIR
4. GitVersion calculates version '2.0.1':

INFO [11/30/21 17:53:01:29] Begin: Calculating base versions
    INFO [11/30/21 17:53:01:29] Fallback base version: 0.1.0 with commit count source 5777b45590f028c9ad3e3e71aa9d5d9f5bbcf142
    INFO [11/30/21 17:53:01:30] Git tag '2.0.0': 2.0.0 with commit count source a3e90ed54605924e5f979ef5045fc893cbaeb759
    INFO [11/30/21 17:53:01:32] Found multiple base versions which will produce the same SemVer (2.0.0), taking oldest source for commit counting (Git tag '2.0.0')
    INFO [11/30/21 17:53:01:32] Base version used: Git tag '2.0.0': 2.0.0 with commit count source a3e90ed54605924e5f979ef5045fc893cbaeb759
  INFO [11/30/21 17:53:01:32] End: Calculating base versions (Took: 27.07ms)
  INFO [11/30/21 17:53:01:32] 0 commits found between a3e90ed Update .gitlab-ci.yml file and a3e90ed Update .gitlab-ci.yml file
  INFO [11/30/21 17:53:01:32] Begin: Using mainline development mode to calculate current version
    INFO [11/30/21 17:53:01:33] Found possible mainline branches: main
    INFO [11/30/21 17:53:01:33] Mainline for current branch is main
    INFO [11/30/21 17:53:01:33] Detected forward merge at a3e90ed Update .gitlab-ci.yml file; rewinding mainline to previous commit 5777b45 Initial commit
    INFO [11/30/21 17:53:01:33] Current branch (2.0.0) was branch from 5777b45 Initial commit
    INFO [11/30/21 17:53:01:33] 1 commits found between 5777b45 Initial commit and a3e90ed Update .gitlab-ci.yml file
    INFO [11/30/21 17:53:01:33] Performing Patch increment for current branch 
  INFO [11/30/21 17:53:01:33] End: Using mainline development mode to calculate current version (Took: 8.85ms)

Executing GenerateSetVersionMessage for 'GitLabCi'.
2.0.1-2-0-0.1
Executing GenerateBuildLogOutput for 'GitLabCi'.
GitVersion_Major=2
GitVersion_Minor=0
GitVersion_Patch=1

But when cloning the Repository locally and running dotnet-gitversion -overrideconfig mode=Mainline -diag against the local clone it calculates the version '2.0.0' as expected:

INFO [11/30/21 17:55:28:01] Begin: Calculating base versions
  INFO [11/30/21 17:55:28:02] Fallback base version: 0.1.0 with commit count source 5777b45590f028c9ad3e3e71aa9d5d9f5bbcf142
  INFO [11/30/21 17:55:28:03] Git tag '2.0.0': 2.0.0 with commit count source a3e90ed54605924e5f979ef5045fc893cbaeb759
  INFO [11/30/21 17:55:28:07] Found multiple base versions which will produce the same SemVer (2.0.0), taking oldest source for commit counting (Git tag '2.0.0')
  INFO [11/30/21 17:55:28:07] Base version used: Git tag '2.0.0': 2.0.0 with commit count source a3e90ed54605924e5f979ef5045fc893cbaeb759
  INFO [11/30/21 17:55:28:07] End: Calculating base versions (Took: 59.44ms)
  INFO [11/30/21 17:55:28:07] 0 commits found between a3e90ed Update .gitlab-ci.yml file and a3e90ed Update .gitlab-ci.yml file
  INFO [11/30/21 17:55:28:07] Begin: Using mainline development mode to calculate current version
    INFO [11/30/21 17:55:28:09] Found possible mainline branches: main
    INFO [11/30/21 17:55:28:09] Mainline for current branch is main
    INFO [11/30/21 17:55:28:10] 0 commits found between a3e90ed Update .gitlab-ci.yml file and a3e90ed Update .gitlab-ci.yml file
  INFO [11/30/21 17:55:28:10] End: Using mainline development mode to calculate current version (Took: 21.52ms)

{
  "Major": 2,
  "Minor": 0,
  "Patch": 0,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.main.Sha.a3e90ed54605924e5f979ef5045fc893cbaeb759",
  "MajorMinorPatch": "2.0.0",
  "SemVer": "2.0.0",
  "LegacySemVer": "2.0.0",
  "LegacySemVerPadded": "2.0.0",
  "AssemblySemVer": "2.0.0.0",
  "AssemblySemFileVer": "2.0.0.0",
  "FullSemVer": "2.0.0",
  "InformationalVersion": "2.0.0+Branch.main.Sha.a3e90ed54605924e5f979ef5045fc893cbaeb759",
  "BranchName": "main",
  "EscapedBranchName": "main",
  "Sha": "a3e90ed54605924e5f979ef5045fc893cbaeb759",
  "ShortSha": "a3e90ed",
  "NuGetVersionV2": "2.0.0",
  "NuGetVersion": "2.0.0",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "a3e90ed54605924e5f979ef5045fc893cbaeb759",
  "CommitsSinceVersionSource": 0,
  "CommitsSinceVersionSourcePadded": "0000",
  "UncommittedChanges": 0,
  "CommitDate": "2021-11-30"
}

Context

• I like to use Mainline mode. (Currently I just override the mode through the command parameter. Later I would use a config file)
• For major versions I like to create a git tag and expected that then the value of the tag is used a the calculated version. (which works locally but not in the GitLab Pipeline).

Your Environment

• Version Used: 5.8.1
• Operating System and version (Windows 10, Ubuntu 18.04): Debian 11 - mcr.microsoft.com/dotnet/sdk:6.0 Docker Container.
• Git Version installed by: dotnet tool install --global GitVersion.Tool --version 5.*
• Link to your project: Private Company Project which I can unfortunately not link here.
• Link to your CI build (if appropriate):

[asbjornu]

This seems like a duplicate of #2301?

[J0F3]

Hmm, I am not quite sure. In my case GitVersion runs just fine, without any errors and generates also the version number. It just bumps the patch version unexpected by one.

For me it seems because, for some reason, when running in the GitLab pipeline it detects a forward merge:

INFO [11/30/21 17:53:01:33] Detected forward merge at a3e90ed Update .gitlab-ci.yml file; rewinding mainline to previous commit 5777b45 Initial commit`
INFO [11/30/21 17:53:01:33] Current branch (2.0.0) was branch from 5777b45 Initial commit
INFO [11/30/21 17:53:01:33] 1 commits found between 5777b45 Initial commit and a3e90ed Update .gitlab-ci.yml file

Which it does not when running locally (with the exacte same state of the repo):

INFO [11/30/21 17:55:28:10] 0 commits found between a3e90ed Update .gitlab-ci.yml file and a3e90ed Update .gitlab-ci.yml file

(See also the full logs above)

Maybe it is because of some "magic" of how gitlab clones the repo but as I have configured the dynamic repo it should probably not matter. I had even disabled the git clone form GitLab but the behavior of GitVersion kept the same.

[asbjornu]

Sounds like the effect of repository normalization, @J0F3. Are you able to turn that off when running on GitLab? If so, how does that affect the version calculation?

[J0F3]

Yes that what I tough too. But I set GIT_STRATEGY to clone which means:

clone is the slowest option. It clones the repository from scratch for every job, ensuring that the local working copy is always pristine. If an existing worktree is found, it is removed before cloning.

But this does not changed anything so I disabled the Git cloning in the GitLab pipeline completely and configured dynamic repositories for GitVersion. If I understand it correctly the normalisation of GitLab should then no be a problem as GitVersion clones the repository itself. But the problem kept the same.

[xgboosted]

It may be a little side topic: the docs say Git Flow and Github Flow is supported, is GitLab Flow not supported?

[asbjornu]

@J0F3, I see. Does passing -nonormalize to GitVersion work?

It may be a little side topic: the docs say Git Flow and Github Flow is supported, is GitLab Flow not supported?

I've never heard about GitLab Flow before today, but I think it should be possible to configure GitVersion to work with it.

[xgboosted]

@asbjornu would it be possible to create an improvement feature based on this suggestion (make GirVersion compatible with GitLab Flow)?

[asbjornu]

I would start with figuring out a configuration that allows GitVersion to properly version GitLab Flow and then move from there. If it's possible to solve this through configuration, we can always document that configuration on gitversion.net. If not, a PR with the required code changes and tests would be welcome, @GolamRashed.

[svenmoon]

I have the same issue as @J0F3 and tried -nonormalize as suggested by @asbjornu. It doesn't change anything.

For me it looks like gitlab creates a branch refs/heads/tagname to run the pipeline on. There it detects a 'forward merge' and is 'rewinding mainline to previous commit'. As a result it finds one commit and increments the patch number.

[asbjornu]

That is interesting and relevant information, @svenmoon. Perhaps the oddity in build server testing discovered in #3033 (review) may be that not only GitHub Actions is having this problem? Ending up with a branch called refs/heads/tagname is at least the exact same problem as have been reported for GitHub Actions in #2838, #2852, #2301 and #2074. Seems like taking a holistic and build server agnostic approach to solving this is the right solution.