Prevent pipline failing when failing to obtain the source branch name

[IT-VBFK]

Ref. https://github.com/fluentassertions/fluentassertions/actions/runs/6169114546/job/16805839918?pr=2296

For some reason this pipline has failed, because Libgit2Sharp failed to obtain the source branch name.
I tried to make this a bit more robust, and running the complete pipeline in such case. (Meaning spell check + "normal" pipeline)

IMPORTANT

• If the PR touches the public API, the changes have been approved in a separate issue with the "api-approved" label.
• The code complies with the Coding Guidelines for C#.
• The changes are covered by unit tests which follow the Arrange-Act-Assert syntax and the naming conventions such as is used in these tests.
• If the PR adds a feature or fixes a bug, please update the release notes with a functional description that explains what the change means to consumers of this library, which are published on the website.
• If the PR changes the public API the changes needs to be included by running AcceptApiChanges.ps1 or AcceptApiChanges.sh.
• If the PR affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
  • Please also run ./build.sh --target spellcheck or .\build.ps1 --target spellcheck before pushing and check the good outcome

[github-actions]

Qodana for .NET

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions

[dennisdoomen]

It seems to have been fixed in GitVersion 6.0.0-beta.2. See GitTools/GitVersion#3103

[IT-VBFK]

But this exception was thown by Libgit2Sharp 🤔

[jnyrup]

The two builds failing for Libgit2Sharp
https://github.com/fluentassertions/fluentassertions/actions/runs/6138313101/job/16687208347
https://github.com/fluentassertions/fluentassertions/actions/runs/6169114546/job/16805839918

both have

19:50:37 [INF] > "C:\Program Files\dotnet\dotnet.exe" C:\Users\runneradmin\.nuget\packages\gitversion.tool\5.10.0\tools\net6.0\any\gitversion.dll /nocache /nofetch
Warning: Could not inject value for "Build.GitVersion"
19:50:38 [WRN] Could not inject value for Build.GitVersion
Nuke.Common.Tooling.ProcessException: Process 'dotnet.exe' exited with code 1.
   > "C:\Program Files\dotnet\dotnet.exe" C:\Users\runneradmin\.nuget\packages\gitversion.tool\5.10.0\tools\net6.0\any\gitversion.dll /nocache /nofetch
   @ D:\a\fluentassertions\fluentassertions

So I suspect that the root cause is either only within GitVersion.Tool or in a deeper places shared by both GitVersion.Tool and Libgit2Sharp.

[IT-VBFK]

Ok, but the pipeline isn't failing if GitVersion cannot be injected, but Libgit2Sharp is failing the whole build.

[dennisdoomen]

Ah yes, the problem is in LibGit2Sharp indeed. So I guess GitVersion worked around it and Nuke hasn't yet. But what I don't understand is what happened that this is happening.

[jnyrup]

I'll conjecture that if Libgit2Sharp hadn't fail the build, it would have failed when GitVersion is unconditionally used.

I haven't understood the root cause of this problem and that's why I'm a bit weary of complicating the build script.

Does it make sense to continue if GitVersion cannot be injected, or should the entire build rather be terminated instead of continuing? (in a broken state)

[IT-VBFK]

Does it make sense to continue if GitVersion cannot be injected, or should the entire build rather be terminated instead of continuing? (in a broken state)

The whole Libgit2Sharp thing is only used to determine which pipeline to run (SpellCheck, Build, or both), because of what changed. If that fails for some reason, the whole build is failing.

If GitVersion cannot be injected, the only thing what is broken, is the version calculation

[jnyrup]

If GitVersion cannot be injected, the only thing what is broken, is the version calculation

That's a quite important thing 😉

We might be talking past each other.
I see that it can be annoying having the unit test step failing if the nuget version cannot be calculated.
I just trying to avoid hiding a problem.

If I run build.ps1 on a copy of FA without git I get this failure.

11:14:50 [WRN] Could not inject value for Build.GitRepository
System.ArgumentException: No parent Git directory for 'C:\dev\fluentassertions_no_git'
   at Nuke.Common.Assert.NotNull[T](T obj, String message, String argumentExpression) in /_/source/Nuke.Utilities/Assert.cs:line 73
   at Nuke.Common.Git.GitRepository.FromLocalDirectory(AbsolutePath directory) in /_/source/Nuke.Build/VCS/GitRepository.cs:line 49
   at Nuke.Common.Git.GitRepositoryAttribute.GetValue(MemberInfo member, Object instance) in /_/source/Nuke.Common/Attributes/GitRepositoryAttribute.cs:line 22
   at Nuke.Common.ValueInjection.ValueInjectionAttributeBase.TryGetValue(MemberInfo member, Object instance) in /_/source/Nuke.Build/Execution/Extensibility/ValueInjectionAttributeBase.cs:line 26
11:14:50 [WRN] Exception was suppressed
System.ArgumentException: No parent Git directory for 'C:\dev\fluentassertions_no_git'
   at Nuke.Common.Assert.NotNull[T](T obj, String message, String argumentExpression) in /_/source/Nuke.Utilities/Assert.cs:line 73
   at Nuke.Common.Git.GitRepository.FromLocalDirectory(AbsolutePath directory) in /_/source/Nuke.Build/VCS/GitRepository.cs:line 49
   at Nuke.Common.Tools.GitVersion.GitVersionAttribute.<GetValue>b__24_0() in /_/source/Nuke.Common/Tools/GitVersion/GitVersionAttribute.cs:line 43
11:14:50 [INF] > "C:\Program Files\dotnet\dotnet.exe" C:\Users\jn\.nuget\packages\gitversion.tool\5.10.0\tools\net6.0\any\gitversion.dll /nocache /nofetch
11:14:51 [WRN] Could not inject value for Build.GitVersion
Nuke.Common.Tooling.ProcessException: Process 'dotnet.exe' exited with code 1.
   > "C:\Program Files\dotnet\dotnet.exe" C:\Users\jn\.nuget\packages\gitversion.tool\5.10.0\tools\net6.0\any\gitversion.dll /nocache /nofetch
   @ C:\dev\fluentassertions_no_git
Error output:
   Cannot find the .git directory

   at Nuke.Common.Tooling.ProcessExtensions.AssertZeroExitCode(IProcess process) in /_/source/Nuke.Tooling/ProcessExtensions.cs:line 39
   at Nuke.Common.Tooling.ProcessTasks.DefaultExitHandler(ToolSettings toolSettings, IProcess process) in /_/source/Nuke.Tooling/ProcessTasks.cs:line 246
   at Nuke.Common.Tools.GitVersion.GitVersionTasks.GitVersion(GitVersionSettings toolSettings) in /_/source/Nuke.Common/Tools/GitVersion/GitVersion.Generated.cs:line 86
   at Nuke.Common.Tools.GitVersion.GitVersionTasks.GitVersion(Configure`1 configurator) in /_/source/Nuke.Common/Tools/GitVersion/GitVersion.Generated.cs:line 124
   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.Build/Execution/Extensibility/ValueInjectionAttributeBase.cs:line 26

Only working when using git but guarding against not being able to retrieve git information just seems a bit paradoxical to me.

[IT-VBFK]

Only working when using git but guarding against not being able to retrieve git information just seems a bit paradoxical to me.

It's just yet another safety bar ;)

But: feel free to close if you disagree :)

[dennisdoomen]

Are we chasing a ghost here? The builds seem to be fine right now.

[jnyrup]

I'm positive for safety bars, but for the right reasons.

If I outcomment [GitVersion(Framework = "net6.0", NoCache = true, NoFetch = true)] to simulate when GitVersion cannot be injected (and assuming the underlying issues is what Libgit2Sharp experiences), I get the flow below on both develop and this PR.

SpellCheck
Push
  OnlyWhenDynamic(() => RunAllTargets || HasSourceChanges)
  Clean
  Restore
  Compile
    OnlyWhenDynamic(() => RunAllTargets || HasSourceChanges)
    WhenNotNull(GitVersion // <-- guards against GitVersion being null
    SetAssemblyVersion(GitVersion.AssemblySemVer) // <-- NRE because it assumes GitVersion is non-null

If we're to change anything here, how about put a very early guard on GitVersion and stop the entire build with a message like "GitVersion could not be retrieved, please try running the build again".

[jnyrup]

It seems [Nuke.Common.Required] is what I'm looking for.
Let's put annotate GitVersion and GitRepository with that attribute.

History:
We started out with Nuke 0.22 in #1122 and nuke-build/nuke#528 in 0.25 changed the behavior to requiring [Required].

[jnyrup]

I've created #2304 for the attributes.
Then hopefully we'll get a better error if this problems happens again.

@IT-VBFK Thank you for keeping an eye on the pipelines, I hadn't noticed this problem.

[IT-VBFK]

@IT-VBFK Thank you for keeping an eye on the pipelines, I hadn't noticed this problem.

No problem :)

Just can't get around if a build is failing more or less for no reason..

[IT-VBFK]

https://github.com/fluentassertions/fluentassertions/actions/runs/6303031461/job/17111443539

And.. it happens again.. can it be, that force pushing the branch with high frequency could cause this?
(See all actions for #2318)

[jnyrup]

can it be, that force pushing the branch with high frequency could cause this?

That's what I would put my money on.

[jnyrup]

The issues in https://github.com/GitTools/GitVersion/issues?q=%22remote+tips%22 also mentions force pushing as a possible reason for Couldn't find any remote tips from remote 'https://github.com/fluentassertions/fluentassertions' pointing at the commit '1fe1a41baf984b63d5afe09370ab3681ce778eaa'.