-
Usage InformationNuke 6.2.1, .NET 6, DevOps Pipeline using "windows_latest", leveraging GitVersion.CommandLine package v5.10.3 DescriptionSimilar 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 StepsUse the GitVersion.CommandLine package
Include the GitVersion tooling in the Build.cs file:
Consume the property, causing it to lazy-load/initialize which then fails due to a null reference exception. I.e.
Expected BehaviorGitVersion tooling should be injected and available for consuming. Actual BehaviorNullReferenceException is throw since the GitVersion property was not injected correctly. 20:03:28 [WRN] Could not inject value for Build.GitVersion
at Nuke.Common.Tooling.ProcessExtensions.AssertZeroExitCode(IProcess process) in //source/Nuke.Common/Tooling/ProcessExtensions.cs:line 39 Regression?No, other repos are using the same versions of Nuke & GitVersion and work fine. Known WorkaroundsNo workaround identified; Very hard to triage why the injection fails / what GitVersion is struggling with that only applies when running in the pipeline. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
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 s…