Support unit testing NB.GV on Ubuntu 20.04/.NET 3.1

[qmfrederik]

I'm attempting to get dotnet test for the NerdBank.GitVersioning solution itself to work on Ubuntu 20.04 + .NET Core 3.1, since I want to run the unit tests for #521 locally.

Loading LibGit2Sharp fails because:

1. There's no version of LibGit2Sharp which supports Ubuntu 20.04
2. NerdBank.GitVersioning works around this by means of GitLoaderContext, but the unit tests do not execute within the scope of the GitLoaderContext.

I didn't see a straightforward way to replicate the ContextAwareTask approach to unit tests, so I used NativeLibrary.SetDllImportResolver instead.

PS - NativeLibrary is available starting with .NET Core 3.0, so if you're fine having nbgv target at least .NET Core 3.0, we can get rid of the GitLoaderContext/ContextAwareTask and use the NativeLibrary.SetDllImportResolver approach instead.

[AArnott]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[AArnott]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[AArnott]

if you're fine having nbgv target at least .NET Core 3.0,

I am not. .NET Core 2.1 SDK is still under LTS so I want to keep supporting it.

[AArnott]

What you have looks fine. But can you modify the Azure Pipeline to actually run the tests on Ubuntu 20 to 'lock in' your work?

[AArnott]

Also: this PR fails the build (which I had to kick off manually).

[AArnott]

Looks good. But check this build for failures.

[AArnott]

Closer... Windows builds now but linux still has a build break.

[AArnott]

another build given your latest push.

I really wish AzP would fix their bug and auto-trigger.

[qmfrederik]

@AArnott Thanks. I configured Azure Pipelines to run on my fork, so I can trigger my own builds (hence the additional eq(variables['System.TeamFoundationCollectionUri'], 'https://dev.azure.com/andrewarnott/') in some of the tasks and the upgrade to the Yarn@3 task).

Azure DevOps CI for GitHub PRs runs fine on projects I maintain. I wonder whether the failure to trigger builds on PR requests is related to the trigger: declaration at the top of the pipeline declaration. (Documentation says it should not, but there's clearly a bug/issue somewhere).

The Linux task now fails like this:

A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:02.10] NerdBank.GitVersioning.Tests: Catastrophic failure: System.TypeLoadException: Could not load type of field 'Xunit.Runner.VisualStudio.VsExecutionSink:recorder' (4) due to: Could not load file or assembly 'Microsoft.VisualStudio.TestPlatform.ObjectModel, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.


Server stack trace: 
  at (wrapper managed-to-native) System.RuntimeTypeHandle.type_is_assignable_from(System.Type,System.Type)
  at System.RuntimeTypeHandle.CanCastTo (System.RuntimeType type, System.RuntimeType target) [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.RuntimeType.IsAssignableFrom (System.Type c) [0x00020] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.RuntimeTypeHandle.IsContextful (System.RuntimeType type) [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.RuntimeType.IsContextfulImpl () [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Type.get_IsContextful () [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x00041] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Runtime.Remoting.Messaging.CADMessageBase.UnmarshalArgument (System.Object arg, System.Collections.ArrayList args) [0x0003d] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Runtime.Remoting.Messaging.CADMessageBase.UnmarshalArguments (System.Object[] arguments, System.Collections.ArrayList args) [0x00011] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Runtime.Remoting.Messaging.CADMethodCallMessage.GetArgs (System.Collections.ArrayList args) [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.Runtime.Remoting.Messaging.MethodCall..ctor (System.Runtime.Remoting.Messaging.CADMethodCallMessage msg) [0x0001e] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at System.AppDomain.ProcessMessageInDomain (System.Byte[] arrRequest, System.Runtime.Remoting.Messaging.CADMethodCallMessage cadMsg, System.Byte[]& arrResponse, System.Runtime.Remoting.Messaging.CADMethodReturnMessage& cadMrm) [0x00012] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain.ProcessMessageInDomain(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[]&,System.Runtime.Remoting.Messaging.CADMethodReturnMessage&)
  at System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain (System.Byte[] arrRequest, System.Runtime.Remoting.Messaging.CADMethodCallMessage cadMsg) [0x0000d] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 

Exception rethrown at [0]: 
  at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, System.Runtime.Remoting.Messaging.IMessage msg, System.Exception& exc, System.Object[]& out_args) [0x0014d] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0 
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper(intptr,intptr)
  at (wrapper remoting-invoke) Xunit.Sdk.TestFrameworkExecutor`1[Xunit.Sdk.IXunitTestCase].RunTests(System.Collections.Generic.IEnumerable`1<Xunit.Abstractions.ITestCase>,Xunit.Abstractions.IMessageSink,Xunit.Abstractions.ITestFrameworkExecutionOptions)
  at (wrapper xdomain-invoke) Xunit.Sdk.TestFrameworkExecutor`1[Xunit.Sdk.IXunitTestCase].RunTests(System.Collections.Generic.IEnumerable`1<Xunit.Abstractions.ITestCase>,Xunit.Abstractions.IMessageSink,Xunit.Abstractions.ITestFrameworkExecutionOptions)
  at Xunit.Xunit2.RunTests (System.Collections.Generic.IEnumerable`1[T] testCases, Xunit.Abstractions.IMessageSink messageSink, Xunit.Abstractions.ITestFrameworkExecutionOptions executionOptions) [0x0000e] in <4d712162c0a34cb99c967a7a106084df>:0 
  at Xunit.XunitFrontController.RunTests (System.Collections.Generic.IEnumerable`1[T] testMethods, Xunit.Abstractions.IMessageSink messageSink, Xunit.Abstractions.ITestFrameworkExecutionOptions executionOptions) [0x00006] in <4d712162c0a34cb99c967a7a106084df>:0 
  at TestFrameworkExtensions.RunTests (Xunit.Abstractions.ITestFrameworkExecutor executor, System.Collections.Generic.IEnumerable`1[T] testCases, Xunit.IMessageSinkWithTypes executionMessageSink, Xunit.Abstractions.ITestFrameworkExecutionOptions executionOptions) [0x00008] in <4d712162c0a34cb99c967a7a106084df>:0 
  at Xunit.Runner.VisualStudio.VsTestRunner.RunTestsInAssembly (Microsoft.VisualStudio.TestPlatform.ObjectModel.Adapter.IRunContext runContext, Microsoft.VisualStudio.TestPlatform.ObjectModel.Adapter.IFrameworkHandle frameworkHandle, LoggerHelper logger, Xunit.Runner.VisualStudio.TestPlatformContext testPlatformContext, Xunit.Runner.VisualStudio.RunSettings runSettings, Xunit.IMessageSinkWithTypes reporterMessageHandler, Xunit.Runner.VisualStudio.AssemblyRunInfo runInfo) [0x00511] in <42d73e9a900048ada4679362440112c9>:0 
No test matches the given testcase filter `TestCategory!=FailsOnAzurePipelines` in /home/vsts/work/1/s/bin/NerdBank.GitVersioning.Tests/Release/net461/NerdBank.GitVersioning.Tests.dll

Anything that's immediately obvious to you?

[qmfrederik]

@AArnott CI on my end looks green now: https://dev.azure.com/qmfrederik/NerdBank.GitVersioning/_build/results?buildId=2014&view=logs&j=d8b3a81b-d734-5e0d-546c-0de194b18bbe&t=d8b3a81b-d734-5e0d-546c-0de194b18bbe

[AArnott]

Azure DevOps CI for GitHub PRs runs fine on projects I maintain

Is your service connection between Azure DevOps and GitHub based on OAuth or the Azure Pipelines GitHub App? Mine is the latter, and generally provides a superior experience. But I wonder if switching to OAuth for now would fix it.