[ISSUE]: GitVersion is undefined in Azure DevOps on PR builds using GitTools 3.1.1

[officeSpacePirate]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

AzureDevops task

GitVersion version

6.0.5

Operating system

Linux

What are you seeing?

I recently updated to the new GitTools tasks from UseGitVersion@5 along with new config and have had no issues building code for approximately a week. When I opened a pull request today, the automatic build triggered by our PR requirement failed stating that GitVersion is undefined. Looking at the logs, I can see that the checkout process is working as expected with all our most recent commits to the repository and we automatically tag every commit into master/main branches so history shouldn't be an issue. Any suggestions/workarounds would be appreciated.

What is expected?

Pull request builds should behave the same way when using GitTools in Azure DevOps.

Steps to Reproduce

# azure-pipelines.yaml job template
parameters:
- name: DependsOn
  type: object
  default: []

jobs:
- job: AdoBuildNumber
  dependsOn: ${{ parameters.DependsOn }}
  pool:
    name: 'ubuntu-latest'
  steps:  
  - checkout: self
    fetchDepth: 0

  - task: gitversion/setup@3.1.1
    displayName: Install GitVersion
    inputs:
      versionSpec: '6.0.x'

  - task: gitversion/execute@3.1.1
    displayName: Determine Version
    name: git_version  # variable to use in subsequent steps
    inputs:
      overrideConfig: |
        update-build-number=false
  
  - pwsh: |
      $build_number = "$(git_version.majorMinorPatch)-$(git_version.preReleaseLabel)-$(git_version.buildMetaData)"
      echo "##vso[build.updatebuildnumber]$($build_number)"
    displayName: 'Set Build Number using GitVersion'

# GitVersion.yaml
workflow: GitHubFlow/v1
strategies:
  - Mainline
assembly-versioning-format: '{MajorMinorPatch}-{PreReleaseLabel}-{BuildMetaData}'

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

Starting: Determine Version
==============================================================================
Task         : Execute GitVersion Task
Description  : Easy Semantic Versioning (https://semver.org) for projects using Git
Version      : 3.1.1
Author       : GitTools Contributors
Help         : See the [documentation](https://gitversion.net/docs/) for help
==============================================================================
Running on: 'Azure Pipelines'
Disable Telemetry
Command: git -C /agent/_work/15/s rev-parse --is-shallow-repository
Command: /opt/hostedtoolcache/GitVersion.Tool/6.0.5/dotnet-gitversion /agent/_work/15/s /output json /l console /overrideconfig update-build-number=false
##[error]GitVersion output is not valid JSON
dotnet-gitversion Output:
-------------------
undefined
-------------------
undefined
Finishing: Determine Version

[ChaosYoda]

I am running into the same issue, it seems to help to throw all the old agents away and try again. Seems the default Azure pipeline behavior is to do a detached head checkout, even if you set the fetchDepth: 0

[DaveSkender]

This occurs on GitHub Actions too, so it's not likely an Azure DevOps specific issue.

I think in the end though the real problem here is that it takes a PhD to understand all the configuration options and all the different tool implementation options. I haven't solved all my problems, but am making progress by running the underlying dotnet-gitversion commands, which seem to produce better debugging information about your setup.

# GitHub Action workflow, for troubleshooting
    runs-on: ubuntu-latest
    steps:

      - name: Checkout source
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Check GitVersion config presence
        run: cat src/gitversion.yml

      - name: Setup GitVersion Tool
        run: dotnet tool install --global GitVersion.Tool --version 6.0.5

      - name: Show GitVersion config
        run: dotnet-gitversion /showconfig /config src/gitversion.yml

        # for comparison, this is the same as the "execute" pre-built step
      - name: Show GitVersion config (with Json output)
        run: dotnet-gitversion /output json /l console /config src/gitversion.yml

The pre-defined gittools/actions/gitversion setup and execute tasks mostly look like they're just executing these dotnet commands anyway, but they don't seem to handle errors well or report problems with configs, just BSD types of feedback.

Pre-defined GitHub Action tasks and output, for comparison

      - name: Setup GitVersion
        uses: gittools/actions/gitversion/setup@v3
        with:
          versionSpec: "6.0.5"

      - name: Determine version
        id: gitversion
        uses: gittools/actions/gitversion/execute@v3
        with:
          useConfigFile: true
          configFilePath: src/gitversion.yml
          updateAssemblyInfo: true

Run gittools/actions/gitversion/setup@v3.1.1
  with:
    versionSpec: 6.0.5
    includePrerelease: false
    ignoreFailedSources: false
    preferLatestVersion: false
Running on: 'GitHub Actions'
Disable Telemetry
--------------------------
Acquiring GitVersion.Tool for version spec: 6.0.5
--------------------------
Looking for local tool GitVersion.Tool@6.0.5
Directory /opt/hostedtoolcache/GitVersion.Tool/6.0.5 not found
Command: dotnet tool install GitVersion.Tool --tool-path /home/runner/work/_temp/2cddf8c4-6e0e-4e25-b7b9-551db7b265ae --version 6.0.5
--------------------------
GitVersion.Tool version: 6.0.5 installed.
--------------------------
Prepending /opt/hostedtoolcache/GitVersion.Tool/6.0.5 to PATH
Updated PATH: /opt/hostedtoolcache/GitVersion.Tool/6.0.5:/snap/bin:/home/runner/.local/bin:/opt/pipx_bin:/home/runner/.cargo/bin:/home/runner/.config/composer/vendor/bin:/usr/local/.ghcup/bin:/home/runner/.dotnet/tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Set GITVERSION_PATH to /opt/hostedtoolcache/GitVersion.Tool/6.0.5
dotnet-gitversion Output:
-------------------
undefined
-------------------

gittools/actions/gitversion/execute@v3.1.1
  with:
    useConfigFile: true
    targetPath: /home/runner/work/MyRepoName/MyRepoName
    configFilePath: src/gitversion.yml
    disableCache: false
    disableNormalization: false
    disableShallowCloneCheck: false
    updateAssemblyInfo: false
  env:
    DOTNET_CLI_TELEMETRY_OPTOUT: true
    DOTNET_NOLOGO: true
    DOTNET_ROOT: ../lib/dotnet
    GITVERSION_PATH: /opt/hostedtoolcache/GitVersion.Tool/6.0.[5](https://github.com/MyOrgName/MyRepoName/actions/runs/12541632759/job/34970406692#step:5:5)
Running on: 'GitHub Actions'
Disable Telemetry
Command: git -C /home/runner/work/MyRepoName/MyRepoName rev-parse --is-shallow-repository
Command: /opt/hostedtoolcache/GitVersion.Tool/[6](https://github.com/MyOrgName/MyRepoName/actions/runs/12541632759/job/34970406692#step:5:6).0.5/dotnet-gitversion /home/runner/work/MyRepoName/MyRepoName /output json /l console /config src/gitversion.yml
Error: GitVersion output is not valid JSON
dotnet-gitversion Output:
-------------------
undefined
-------------------

[HHobeck]

Can you reproduce it locally and provide steps to reproduce? The undefined value is a strange result which I see the first time. Is this error related to the configuration (Mainline version strategy in combination with GitHubFlow/v1)? What happen if you just use the GitHubFlow/v1 or TrunkBased/preview1 workflow template without customization? Is it related to your repository? What happen if you use a vanilla git repository?

[officeSpacePirate]

@HHobeck I tried going back to the GitVersion task using v6.0.x to see whether it would be a viable workaround. The build still fails, but it looks like GitVersion is failing to calculate on a PR branch. Here's the error from my build output:

ERROR [24-12-30 14:02:27:54] An unexpected error occurred:
System.InvalidOperationException: Operation is not valid due to the current state of the object.
   at GitVersion.VersionCalculation.MainlineVersionStrategy.GetCommitsWasBranchedFrom(IBranch branch, IBranch[] excludedBranches) in /_/src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs:line 299
   at GitVersion.VersionCalculation.MainlineVersionStrategy.<>c__DisplayClass13_0.<IterateOverCommitsRecursive>b__0() in /_/src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs:line 143
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at GitVersion.VersionCalculation.MainlineVersionStrategy.IterateOverCommitsRecursive(IEnumerable`1 commitsInReverseOrder, MainlineIteration iteration, IBranch targetBranch, String targetLabel, ILookup`2 taggedSemanticVersions, HashSet`1 traversedCommits) in /_/src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs:line 150
   at GitVersion.VersionCalculation.MainlineVersionStrategy.IterateOverCommitsRecursive(IEnumerable`1 commitsInReverseOrder, MainlineIteration iteration, IBranch targetBranch, String targetLabel, ILookup`2 taggedSemanticVersions, HashSet`1 traversedCommits) in /_/src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs:line 258
   at GitVersion.VersionCalculation.MainlineVersionStrategy.GetBaseVersions(EffectiveBranchConfiguration configuration)+MoveNext() in /_/src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs:line 105
   at GitVersion.VersionCalculation.NextVersionCalculator.<>c__DisplayClass14_0.<<GetNextVersions>g__GetNextVersionsInternal|0>d.MoveNext() in /_/src/GitVersion.Core/VersionCalculation/VersionCalculators/NextVersionCalculator.cs:line 264
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at GitVersion.VersionCalculation.NextVersionCalculator.GetNextVersions(IBranch branch, IGitVersionConfiguration configuration) in /_/src/GitVersion.Core/VersionCalculation/VersionCalculators/NextVersionCalculator.cs:line 239
   at GitVersion.VersionCalculation.NextVersionCalculator.CalculateNextVersion(IBranch branch, IGitVersionConfiguration configuration) in /_/src/GitVersion.Core/VersionCalculation/VersionCalculators/NextVersionCalculator.cs:line 158
   at GitVersion.VersionCalculation.NextVersionCalculator.FindVersion() in /_/src/GitVersion.Core/VersionCalculation/VersionCalculators/NextVersionCalculator.cs:line 53
   at GitVersion.GitVersionCalculateTool.CalculateVersionVariables() in /_/src/GitVersion.Core/Core/GitVersionCalculateTool.cs:line 45
   at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions) in /_/src/GitVersion.App/GitVersionExecutor.cs:line 66

Just to reiterate, the configuration I've mentioned so far works as expected locally and when building a branch directly in ADO; the failure only occurs for pull request builds. I'll try a few different configurations and get back to you if I have any luck.

[officeSpacePirate]

@HHobeck Alright, I tried a few different configurations and it looks like Mainline is the problem. Hopefully this makes sense based on the error output in my previous comment. The configuration in my original post works if you simply remove the strategies property. I think this points to the issue being between v5.x and v6.x rather than the GitVersion task or ADO/GitHub.

The problem is, I'm now unsure how to get my versioning structured the way I expect coming from v5. Is this a bug on GitVersion's end or do I need to change my configuration? Here's what we have on our master branch today using v5 in a .NET repository:

mode: Mainline
# not sure why we are overriding this; I added an override in the new config to have a property on the GitVersion object that was unique without +'s for Docker/ECR
assembly-informational-format: '{NuGetVersionV2}+{Sha}'

[HHobeck]

Please try the TrunkBased/preview1 workflow:

• Mainline in 6.0.0 with default configuration values throws #4236 (reply in thread)

If you have a merge from main to your feature or hotfix branch then this can be a problem as well. You should know currently
the feature to support multi mainline branches in the Mainline version strategy (#4057) is not implemented.

[DaveSkender]

This occurs on GitHub Actions too ...

For my situation, I was able to determine that the issue is with the built-in task:

# what the built-in gittools/actions/gitversion task does
# produces error: Cannot find the .git directory
dotnet-gitversion /output json /l console /config src/gitversion.yml

# works as expected
dotnet-gitversion -output json -l console -config src/gitversion.yml

In other words, the built-in task is using / argument syntax that does seem to work. And just an FYI, with these commands dotnet-gitversion and dotnet gitversion both work, but gitversion alone does not.

[officeSpacePirate]

@HHobeck I was able to get a successful build after changing to TrunkBased, though it looks like the GitVersion property values change pretty significantly so I'll have to make sure I understand the expectations there.

On a different note, it appears that the build only works when using the old GitVersion task. When I change back to the new way of doing things, I'm getting undefined as mentioned above. It's possible that @DaveSkender has already determined the root issue to that though.

[officeSpacePirate]

In case anyone else is running into this issue, here's my current workaround:

# GitVersion.yaml
workflow: TrunkBased/preview1
strategies:
  - Mainline
assembly-versioning-format: '{MajorMinorPatch}-{PreReleaseLabel}-{CommitsSinceVersionSource}'

# azure-pipelines.yaml job template
parameters:
- name: DependsOn
  type: object
  default: []

jobs:
- job: AdoBuildNumber
  dependsOn: ${{ parameters.DependsOn }}
  pool:
    name: 'ubuntu-latest'
  steps:  
  - checkout: self
    fetchDepth: 0

  - task: UseGitVersion@5
    displayName: Use GitVersion
    inputs:
      versionSpec: '6.0.x'

  - pwsh: |
      $build_number = "$(GitVersion.majorMinorPatch)-$(GitVersion.preReleaseLabel)-$(GitVersion.commitsSinceVersionSource)"
      echo "##vso[build.updatebuildnumber]$($build_number)"
    displayName: 'Set Build Number using GitVersion'

The use of CommitsSinceVersionSource is to avoid +'s because they are invalid characters in versions for container registries. It looks like using TrunkBased doesn't include one now, but GitHubFlow does so I'm simply being explicit. Another note is that the BuildMetaData property is null when using TrunkBased, so I decided on the one that seemed to make the most sense.

[HHobeck]

The use of CommitsSinceVersionSource is to avoid +'s because they are invalid characters in versions for container registries. It looks like using TrunkBased doesn't include one now, but GitHubFlow does so I'm simply being explicit. Another note is that the BuildMetaData property is null when using TrunkBased, so I decided on the one that seemed to make the most sense.

Please see following Q/A:

• V5 to v6 migration is not going smoothly #4352

[officeSpacePirate]

The use of CommitsSinceVersionSource is to avoid +'s because they are invalid characters in versions for container registries. It looks like using TrunkBased doesn't include one now, but GitHubFlow does so I'm simply being explicit. Another note is that the BuildMetaData property is null when using TrunkBased, so I decided on the one that seemed to make the most sense.

Please see following Q/A:

• V5 to v6 migration is not going smoothly #4352

@HHobeck That's actually what I tried first, but it is not unique between builds/commits. When automatically publishing packages, I essentially need the FullSemVer, but without a + in it. Since BuildMetaData is null when using TrunkBased, I opted for CommitsSinceVersionSource. Another option would be to use ShortSha if character length is not an issue.

[HHobeck]

@HHobeck That's actually what I tried first, but it is not unique between builds/commits. When automatically publishing packages, I essentially need the FullSemVer, but without a + in it. Since BuildMetaData is null when using TrunkBased, I opted for CommitsSinceVersionSource. Another option would be to use ShortSha if character length is not an issue.

I don't understand what you are writing. If you use the Continues Deployment mode then the pre-release number will be incremented on every commit. I think you have a misunderstanding about how the modes are working. Even though in the TrunkBased/preview1 workflow you can customize it (the pre-release number will be always 1 on the main branch because of the Mainline version strategy algorithm).

[ChaosYoda]

I think what he is trying to say is that Continuous Deployment mode will keep incrementing but with a +<number> at the end. This is not compatible with Nuget versioning, even though the number is accepted nuget drops off the +<number> and it leaves you with the same version as the previous build, where v5 had the padded commit number which could be used. The problem is mainly that the +234 or whatever postfix is not compatible.

[officeSpacePirate]

I don't understand what you are writing. If you use the Continues Deployment mode then the pre-release number will be incremented on every commit. I think you have a misunderstanding about how the modes are working. Even though in the TrunkBased/preview1 workflow you can customize it (the pre-release number will be always 1 on the main branch because of the Mainline version strategy algorithm).

Are you saying that the default mode is ManualDeployment? I was under the impression that it was ContinuousDelivery, which is what I want.

To be specific, the repo I'm updating is currently set to v5 and the following:

# complete GitVersion.yaml
mode: Mainline
assembly-informational-format: '{NuGetVersionV2}+{Sha}'

Which results in FullSemVer as {Major}.{Minor}.{Patch}-{EscapedBranchName}.{PreReleaseNumber or CommitsSinceVersionSource}

---

I updated to v6 and tried:

# GitVersion.yaml
workflow: GitHubFlow/v1
strategies:
  - Mainline

Which results in FullSemVer as {Major}.{Minor}.{Patch}-{EscapedBranchName}.{PreReleaseNumber}+{BuildMetaData or CommitsSinceVersionSource}. In this case, PreReleaseNumber is always 1 no matter how many commits I have on a non-main branch. I also can't have the + for building or publishing containers, so I added the override to use the AssemblySemVer as my default. This configuration is also the one that works locally and when building a branch directly in ADO, but does not work when building pull requests.

---

I then opened this GitHub issue and tried your suggestion:

# GitVersion.yaml
workflow: TrunkBased/preview1
strategies:
  - Mainline

Which results in FullSemVer as {Major}.{Minor}.{Patch}-{EscapedBranchName}.{PreReleaseNumber or CommitsSinceVersionSource}. In this case, BuildMetaData is always null, but the FullSemVer doesn't have a + in it causing an issue either. As I mentioned above, I only kept the custom versioning because of the differences between GitHubFlow / TrunkBased and I wanted to be explicit. This also resolves the issue I'm having with PR builds so long as I use UseGitVersion@5 instead of gitversion/execute@3.1.1 for now.