Eliminate duplicates in Helix TestRunner

[dougbu]

• do not add source that's already in NuGet.config
  • configuration file now part of Helix content
• do not set env variable set in runtests.*

nit: simplify `%Path% setting in runtests.cmd

• always quote the value

[HaoK]

Have you confirmed the path issues no longer occur? There's a few queues that have spaces due to jdk paths which used to die miserably, issues might only show up if you run the full matrix

[dougbu]

1. This SET set command didn't cause that problem; we invoke dotnet-install.ps1 w/ -noPath to avoid that
2. The issue here apparently was parentheses in the %PATH% value causing script parsing problems; I chose the more common way to deal with that.

FYI…

Set path to: "C:\h\w\AE0A0984\p\sdk\x64;C:\python3.7.0\lib\site-packages\pywin32_system32;C:\python3.7.0\Scripts\;C:\python3.7.0\;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Users\runner\AppData\Local\Microsoft\WindowsApps;C:\h\w\AE0A0984\p\node\bin"

[dougbu]

BTW spaces are fine when using this quoted syntax too

[HaoK]

If you say so, that's how things started, but we'll find out soon enough :)

[HaoK]

But yeah I guess the issue I recall is with parens causing issues with IF parsing, not spaces so its only machines that have the "C:\Program Files (x86)";

[HaoK]

I'd suggest running this through the full helix queue before merging regardless when mucking with runtests.cmd

[HaoK]

We might be okay since we don't use the path inside an IF anymore in this script which I think we used to do

[dougbu]

This syntax works fine for all the cases you want to throw at it other than nesting in ifs but I kicked off https://dev.azure.com/dnceng/public/_build/results?buildId=804251

Side note: That matrix only runs for the master branch and is completely on the floor. Hope #25650 gets it going again.

[HaoK]

RE: side note, is that a good idea to not run the matrix something like once a day in release branches, there's both risk in product platform regressions and even test only issues that cause the matrix to break will be hard to isolate when merging back to master if it never is run

[dougbu]

I agree w/ you @HaoK Something worth adding though not in this PR.

[dougbu]

My aspnetcore-helix-matrix run failed for familiar problems. The main job hit the PDB duplicates issue from #25293 and the ARM64 job failed due to #25397. @halter73 @sebastienros @JunTaoLuo have we made any progress on either problem❔

I'll fix #25397 in this PR.

FYI

/home/vsts/work/1/s/.dotnet/sdk/5.0.100-rc.1.20379.10/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file '/home/vsts/work/1/s/artifacts/obj/Microsoft.AspNetCore.App.Runtime/project.assets.json' doesn't have a target for 'net5.0/linux-arm64'. Ensure that restore has run and that you have included 'net5.0' in the TargetFrameworks for your project. You may also need to include 'linux-arm64' in your project's RuntimeIdentifiers. [/home/vsts/work/1/s/src/Framework/App.Runtime/src/Microsoft.AspNetCore.App.Runtime.csproj]

[dougbu]

New aspnetcore-helix-matrix run is https://dev.azure.com/dnceng/public/_build/results?buildId=804758

[dougbu]

Latest aspnetcore-helix-matrix run is https://dev.azure.com/dnceng/public/_build/results?buildId=804868

[dougbu]

@Tratcher @jkotalik @BrennanConroy we've got a lot of open dotnet-watch issues at the moment e.g.

• Investigate test failures for dotnet-watch on ARM #23360
• Investigate dotnet-watch failures #23394
• dotnet watch tests timing out #24841

I'm not sure how many of these I hit w/ this PR on ARM64 but https://helix.dot.net/api/2019-06-17/jobs/a11e919b-b39a-4636-b962-50da99624b7c/workitems/dotnet-watch.Tests--net5.0/console doesn't look good. Should most of the dotnet-watch tests be skipped on ARM64❔

[dougbu]

Separately, are we seeing test host crashes on ARM64 frequently @pranavkm and @HaoK❔ Same aspnetcore-helix-matrix build hit the following in run on (Debian.9.Arm64.Open)[email protected]/dotnet-buildtools/prereqs:debian-9-helix-arm64v8-a12566d-20190807161036. See https://helix.dot.net/api/2019-06-17/jobs/6859e6fb-da1f-441d-bb25-c91b760c108a/workitems/Microsoft.AspNetCore.Mvc.Core.Test--net5.0/console

The active test run was aborted. Reason: Test host process crashed
Results File: /root/helix/work/workitem/TestResults/TestResults.xml

Attachments:
  /root/helix/work/workitem/TestResults/6a80c879-7b2d-4371-8f44-abac91b09058/Sequence_430b29a63947420ea8732588d1ed46a5.xml
Test Run Aborted.
Total tests: Unknown
     Passed: 664
 Total time: 4.3276 Minutes

The active Test Run was aborted because the host process exited unexpectedly while executing following test(s):
Microsoft.AspNetCore.Mvc.Routing.ConsumesMatcherPolicyTest.INodeBuilderPolicy_AppliesToEndpoints_EndpointWithoutContentTypes_ReturnsFalse

'/root/helix/work/workitem/.dotnet30126/dotnet test Microsoft.AspNetCore.Mvc.Core.Test.dll --logger:xunit --logger:"console;verbosity=normal" --blame "CollectHangDump;TestTimeout=5m" --TestCaseFilter:"Quarantined!=true|Quarantined=false"' completed with exit code '1'
Failure in non-quarantined tests. Exit code: 1.

[dougbu]

@HaoK in any case, the jobs were successfully submitted to all Helix agents in the most recent aspnetcore-helix-matrix build. Problems above are unrelated to my changes.

[Tratcher]

@Tratcher @jkotalik @BrennanConroy we've got a lot of open dotnet-watch issues at the moment e.g.

• Investigate test failures for dotnet-watch on ARM #23360
• Investigate dotnet-watch failures #23394
• dotnet watch tests timing out #24841

I'm not sure how many of these I hit w/ this PR on ARM64 but https://helix.dot.net/api/2019-06-17/jobs/a11e919b-b39a-4636-b962-50da99624b7c/workitems/dotnet-watch.Tests--net5.0/console doesn't look good. Should most of the dotnet-watch tests be skipped on ARM64❔

@pranavkm is a better person to answer that.