[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/[email protected]
    displayName: Install GitVersion
    inputs:
      versionSpec: '6.0.x'

  - task: gitversion/[email protected]
    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/[email protected]
  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 [email protected]
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/[email protected]
  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/[email protected] for now.

[HHobeck]

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.

It depends on what branch you are building and what template you are using. If you take a look to e.g. the GitHubFlow/v1 workflow template:

• https://gitversion.net/docs/reference/configuration#snippet-/docs/workflows/GitHubFlow/v1.yml

You see the ManualDeployment mode for branches:

• release
• feature
• unknown

and ContinuousDelivery mode for branches:

• main
• pull-request

[HHobeck]

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.

I guess we have mixed up thinks here. @arturcic do you have an idea what the problem might be? Are all informationen present in this ticket to reproduce it? Because it seem to me a infrastructure problem, I cannot help.

[DaveSkender]

Here's ^^ a bit of a repro, but generally it's working with my use case, despite the persistent UNDEFINED runner console output.

[officeSpacePirate]

Here's ^^ a bit of a repro, but generally it's working with my use case, despite the persistent UNDEFINED runner console output.

@DaveSkender I'm seeing undefined on the setup step everytime either way; don't know whether the additional info is useful.

---

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.

I guess we have mixed up thinks here. @arturcic do you have an idea what the problem might be? Are all informationen present in this ticket to reproduce it? Because it seem to me a infrastrucutre problem, I cannot help.

@HHobeck From my end, exactly the same configuration will return different results in ADO depending on whether I use UseGitVersion@5 with the version set to v6.0.x or gitversion/[email protected]. The latter works when building locally or building a branch directly, but does not work when auto-building pull request branches; the former always works.

# my entire GitVersion.yaml configuration for a .NET code repository
workflow: TrunkBased/preview1
strategies:
  - Mainline
assembly-versioning-format: '{MajorMinorPatch}-{PreReleaseLabel}-{CommitsSinceVersionSource}'

It might be worth mentioning that ADO (and I believe GitHub Actions as well) automatically create a new branch including the current target branch and the changes in the source branch in the pull request before running any subsequent build steps. I'm not confident on whether that branch is of the target with the source merged in or of the source with the target merged in, but I suspect that this has something to do with GitVersion being unable to determine versioning.

Considering that this works as expected in v5 as well as the deprecated UseGitVersion@5 task, but not the newer task, I would expect this to be a bug on GitVerison's side at this point.

[officeSpacePirate]

@HHobeck I noticed that the Mainline strategy is included in the default config for TrunkBased and decided to test through some additional scenarios. It looks like using the default config works in ADO with the gitversion/[email protected] as expected, so I've gone ahead and removed the two properties I was providing. Based on the build output and the GitVersion docs however, I still have no idea why it worked or why my previous configuration failed with only gitversion/[email protected] and not UseGitVersion@5. It's also worth noting that gitversion/[email protected] has a version constraint that does not allow for v6.1.1 (latest) to be used, but it works without issue if I use UseGitVersion@5.

Since I am completed unblocked, feel free to close this ticket out. If you have time to explain what was causing the issue, I would really appreciate any extra insights for future development. Thanks for all the time you've already given me.