[ISSUE]: GitVersion is undefined in Azure DevOps on PR builds using GitTools 3.1.1 #4350
Comments
|
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 |
|
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 # 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
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: trueRun 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
------------------- |
|
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 |
|
@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: 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. |
|
@HHobeck Alright, I tried a few different configurations and it looks like 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}' |
|
Please try the TrunkBased/preview1 workflow: 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 |
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.ymlIn other words, the built-in task is using |
|
@HHobeck I was able to get a successful build after changing to 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 |
|
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 |
Please see following Q/A: |
@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). |
|
I think what he is trying to say is that Continuous Deployment mode will keep incrementing but with a |
Are you saying that the default 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 I updated to v6 and tried: # GitVersion.yaml
workflow: GitHubFlow/v1
strategies:
- MainlineWhich results in I then opened this GitHub issue and tried your suggestion: # GitVersion.yaml
workflow: TrunkBased/preview1
strategies:
- MainlineWhich results in |
It depends on what branch you are building and what template you are using. If you take a look to e.g. the You see the
and
|
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. |
|
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
@HHobeck From my end, exactly the same configuration will return different results in ADO depending on whether I use # 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 |
|
@HHobeck I noticed that the 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. |
Thanks for the info! Changing the workflow did fix my issue. I had a similar issue in my DevOps pipeline where this stopped working today (2025-01-13 - was working yesterday). In my case the issue was building a pipeline on a bugfix branch. Here is the devops git version config that I am using: - task: gitversion/setup@3
inputs:
versionSpec: "6.0.5"
includePrerelease: false
- task: gitversion/execute@3
displayName: "Create Version"
inputs:
useConfigFile: true
configFilePath: "GitVersion.yml"I can confirm that changing the workflow fixed my issue, changing the GitVersion.yml as follows: workflow: GitHubFlow/v1to workflow: TrunkBased/preview1This thread has saved me some time, so thanks to all! |
|
Noticed the undefined as well in azure devops pipelines when using However when it happens a rebase seems not succeed either so a full new branch is normally created with cherry picks from the one that experiences it.
Hopefully #4057 will get some attention for such weird cases, as trunkbased is really something simpler to use in most cases but the undefined is really a heavy blow when encountered |
|
I had the same error (output was undefined) recently and by adding this step before the gitversion I got it fixed for our organization. I have no clue as to why or how so take this with a grain of salt: |
|
I'm facing the same issue. I've tried to see the differences between @0 and @3 version, as I was using @0 previously and everything was working correctly: trigger:
branches:
include:
- master
pool:
vmImage: windows-2022
steps:
- checkout: self
fetchDepth: 0
- task: gitversion/setup@0
inputs:
versionSpec: '5.12.0'
displayName: 'GitVersion > setup'
- task: gitversion/execute@0
displayName: 'Run > gitversion execute (Windows)'
- task: gitversion/setup@3
inputs:
versionSpec: '5.12.0'
displayName: 'GitVersion > setup'
- task: gitversion/execute@3
displayName: 'Run > gitversion execute (Windows)'Logs from @0: Logs from @3: |
|
I've also encountered the same issue using the gitversion@3 tasks, however none of above solutions worked for me. Running which I've found is an Azure DevOps specification for installing tools (check following doc). In order to handle this, I've configured my pipeline as follows: - task: gitversion/setup@3
displayName: gitversion/setup
inputs:
versionSpec: '6.0.*'
- pwsh: |
$gitVersion = Get-ChildItem "${env:GITVERSION_PATH}" -Filter "dotnet-gitversion"
if (!$gitVersion) {
$gitVersion = Get-ChildItem "${env:GITVERSION_PATH}" -Recurse -Filter "dotnet-gitversion"
Write-Host "Setting 'GITVERSION_PATH' to '$($gitVersion.DirectoryName)'"
Write-Output "##vso[task.setvariable variable=GITVERSION_PATH]$($gitVersion.DirectoryName)"
}
displayName: gitversion/configure
- task: gitversion/execute@3
displayName: gitversion/executeThe second step checks the installation path and adjusts it accordingly. As this is rather an ugly workaround, I'd assume it can be easily fixed. Whenever a build previously failed, I've now get a log like: |
Prerequisites
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@5along 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
RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
The text was updated successfully, but these errors were encountered: