[Bug] GitVersion not producing the correct version when building a version tag in an Azure DevOps pipeline

[dsbut]

Describe the bug
When building a tag that represents a specific version (e.g. 1.1.2) in and Azure DevOps pipeline, using the gitversion/execute@0 task, the version number in the tag is not honoured. Instead, it appears that the version is being incremented, and the tags/1.1.2 segment of the tag repo path (e.g. refs/tags/1.1.2) is being assigned as a PreReleaseTag. This results in the unexpected version number 1.2.0-tags-1-1-2.1.1+8 instead of the expected 1.1.2.

We use a GitFlow branch strategy, and CI triggers on tags (rather than the master branch itself) to trigger builds for Production deployments. For us, being able to produce the correct version number based on a version tag is critical, because our automated processes engage extra steps when build a tag vs merely building the master branch.

We've observed this problem with both GitHub and Azure Repos.

This works as expected with the now deprecated GitVerssion@5 (which I believe still invokes GitVersion 5.1.2) task, and worked fora time with the also obsolete UseGitVersion@5 - but the issue also now manifests with UseGitVersion@5. So, I imagine this is an issue that was introduced into GitVersion itself, rather than the Azure Pipelines task implementations.

Expected Behavior

When building a version tag, such as 1.1.2, the version number produced should be based on the tag, resulting in the version 1.1.2.

Actual Behavior

The version number when building a tag, appears to be based on the tag repo path, and treated as a pre-release version, producing a version number like 1.2.0-tags-1-1-2.1+8.

Steps to Reproduce

All our affected repositories follow the same basic patterns. GitFlow, tagging the release commit with a version tag in the master branch, pushing the version tag to trigger the Production automated build and release process w/ Azure DevOps with a tag-base CI trigger.

GitVersion.yaml

branches:
  hotfix:
    tag: hotfix
  release:
    tag: rc
ignore:
  sha: []
merge-message-formats: {}

azure-pipelines.yml

name: '$(GitVersion_FullSemVer)'

trigger:
  batch: true
  branches:
    include:
     - develop
     - feature/*
     - bugfix/*
     - release/*
     - hotfix/*
  paths:
    include:
    - '*'
    exclude:
    - README.md
  tags:
    include:
    - 1.*

stages:
  - stage: 'Build'
    displayName: 'Build'
    jobs:
      - job: 'Build'
        displayName: 'Build'
                    
        pool:
          vmImage: 'ubuntu-latest'

        steps:
        - task: gitversion/setup@0
          displayName: 'Setup GitVersion'
          inputs:
            versionSpec: '5.x'
        
        - task: gitversion/execute@0
          displayName: 'Execute GitVersion'

        ...

gitversion/execute@0 Log file

See the log file DevOps task execution demonstrating the problem
See attached frrom gitversion/execute@0 task execution, produced with system diagnostics enabled.

Context

All of our existing automated release processes that leveraged tag CI triggers and GitFlow now produce the wrong version number. Now the previously automated process now requires manual intervention, across several different products and repos.

Your Environment

• Build Environment: Azure DevOps MS hosted agent
• Agent Image: ubuntu-latest
• gitversion/execute@0 task: 0.9.4
• GitVersion: 5.3.7

[pfaustinopt]

I'm facing the same problem. With the previous versions of GitVersion for Azure DevOps (UseGitVersion), setting refs/tags/* as a trigger for the pipeline would work correctly:

[asbjornu]

If you take a look at #2231 of which this issue is a pretty precise duplicate, I believe you have stumbled upon #2074. The source of the problem is still unknown, I'm afraid. If anyone have time to investigate, reproduce a failing test, provide a public repository that demonstrates the problem or anything else to help, that would be much appreciated.

Please read through and close as duplicate.

[dsbut]

If anyone have time to investigate, reproduce a failing test, provide a public repository that demonstrates the problem or anything else to help, that would be much appreciated.

@asbjornu - I've created a repo and pipeline that produces the problem in a public DevOps project.

• Repo available here
• A run of the ./azure-pipelines.yml pipeline Git Tag 1.2.1 that produces the FullSemVer value of 1.3.0-tags-1-2-1.1+2.

With this, it should be possible to fork the repo for analysis, and hookup the azure-pipelines.yml to your own Azure DevOps project to reproduce the problem first-hand.

I took a shot at creating an integration test that produces the problem, but I could not produce a failing test. I attempted to author a test that was as faithful a reproduction as possible of how we use GitFlow - PRs for master and develop with no fast-forward merges - thus the version Git Tag is always applied to a merge commit.

Hopefully with this available to you, it can aid in a resolution.

[dsbut]

...further to my previous message. The plot thickens. Prior to staging the repo to produce the issue, I unintentionally created a repository state where building a tag did produce the correct version here. I triggered another build of the 1.2.0 tag, just to be sure, that the result was the same (correct).

Now, after having produced the problem with the 1.2.1 tag (per my previous message). Going back and building the 1.2.0 tag again now produces the problem as well.

[MaurizioPz]

I can contribute my experience to the fact that, it seems to me the the problem arises only if there are other pushed branches. I mean that if (in a gitflow) I finish a hotfix branch (merge to master with tag and merge to dev), prepare a new hotfix branch from master and I push the 3 branches I get the wrong version on the tagged commit (master).
If I only push master, wait for the pipeline to finish, and then push the other branches I get the right version

[lucaritossa]

@gerwinjansen was able to reproduce this issue, please refer to #2074 (comment)

[dsbut]

Closing this issue as it is a duplicate of more than one other issue, and appears to be now well on its way to being addressed in #2074.