Build fails with [ Could not inject value for "Build.GitVersion" ] but only when ran in Azure DevOps pipeline

[bhehe]

Usage Information

Nuke 6.2.1, .NET 6, DevOps Pipeline using "windows_latest", leveraging GitVersion.CommandLine package v5.10.3

Description

Similar to the problem reported in issue #1008 I get the same error with Could not inject value for "Build.GitVersion" and in my case it's an Azure DevOps pipeline.

The repo for this solution/build follows the same approaches/layout as we use in several other repos and we're using almost identical build.cs contents and our build pipeline & gitversion yaml files are almost the same as well.

Being that this fails in injecting the tooling, I'm not seeing anything really helpful in the logged contents/stack trace.

Myself & another engineer have compared this repo to the others that work just fine and we're not seeing anything that would account for why this repo's build fails - and it only fails when ran in the DevOps pipeline.

Any tips/tricks/pointers on how to chase this further would be appreciated.

Reproduction Steps

Use the GitVersion.CommandLine package

<PackageReference Include="GitVersion.CommandLine" Version="5.10.3">
	<PrivateAssets>all</PrivateAssets>
	<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

Include the GitVersion tooling in the Build.cs file:

[GitVersion] readonly GitVersion GitVersion;

Consume the property, causing it to lazy-load/initialize which then fails due to a null reference exception. I.e.

    var versionNumber = GitVersion.NuGetVersionV2;

Expected Behavior

GitVersion tooling should be injected and available for consuming.

Actual Behavior

NullReferenceException is throw since the GitVersion property was not injected correctly.

20:03:28 [WRN] Could not inject value for Build.GitVersion
Nuke.Common.Tooling.ProcessException: Process 'gitversion.exe' exited with code 1.

C:\Users\VssAdministrator.nuget\packages\gitversion.commandline\5.10.3\tools\gitversion.exe /nocache
@ D:\a\1\s

at Nuke.Common.Tooling.ProcessExtensions.AssertZeroExitCode(IProcess process) in //source/Nuke.Common/Tooling/ProcessExtensions.cs:line 39
at Nuke.Common.Tools.GitVersion.GitVersionTasks.GitVersion(GitVersionSettings toolSettings) in //source/Nuke.Common/Tools/GitVersion/GitVersion.Generated.cs:line 83
at Nuke.Common.Tools.GitVersion.GitVersionTasks.GitVersion(Configure`1 configurator) in //source/Nuke.Common/Tools/GitVersion/GitVersion.Generated.cs:line 121
at Nuke.Common.Tools.GitVersion.GitVersionAttribute.GetValue(MemberInfo member, Object instance) in //source/Nuke.Common/Tools/GitVersion/GitVersionAttribute.cs:line 47
at Nuke.Common.ValueInjection.ValueInjectionAttributeBase.TryGetValue(MemberInfo member, Object instance) in /_/source/Nuke.Common/ValueInjection/ValueInjectionAttributeBase.cs:line 25

Regression?

No, other repos are using the same versions of Nuke & GitVersion and work fine.

Known Workarounds

No workaround identified; Very hard to triage why the injection fails / what GitVersion is struggling with that only applies when running in the pipeline.

[bhehe]

The root-cause of this ended up being like the related story, the FetchDepth issue is the main reason.

Turns out that any net-new Build Pipelines created in DevOps is now using the 'Shallow Fetch' option enabled with a depth of 1. This explains why doing what we did before (that still works) doesn't work for any new build pipelines we create. MSFT has changed the defaults it appears.

In your build pipeline, if you select Edit >> Triggers >> YAML and then select the 'Get Sources' step you'll see this option named 'Shallow Fetch' and it being defaulted to Enabled with a Depth of 1. Once I disabled it then everything magically started working.

Hopefully sharing this info saves someone else some headaches and wasted hours. Seems like any build approach using GitVersion would have been impacted by this change in behavior.

[rena0157]

Thank you so much!! I was banging my head on the wall for a while on this one 😆

As a note this also fixes the same issue with GitVersion.Tool as well.

[kornelijepetak]

Can somebody explain why this helps (it does for me too)?

Cause I'm trying to understand why is Nuke's ability to inject the GitVersion related to the amount of stuff fetched from a repo?
I can understand why the GitVersion couldn't work properly without enough of a repo fetched, but to even inject the dep, I don't really get it?

[valadas]

My guess is that GitVersion throws some exception that bubbles up instead of having some default values. Which could make sense to not accidently provide a wrong version.

[igiona]

See here for the same solution for Bitbucket Pipelines: #944 (comment)

[bhehe]

That was my assumption as well. IIRC when I was dealing with it there was definitely an error/exception getting thrown and bubbling up to Nuke's code.