VSTest repo uploading bad data to BAR

• This issue is blocking
• This issue is causing unreasonable pain

Between rc2 and RTM, vstest started causing a failure in gather-drop where the release json file can no longer be generated. The exception is:

fail: Error: Failed to gather drop.
      System.ArgumentException: Repository URI should be in the form https://dev.azure.com/:account/:project/_git/:repo or https://:account.visualstudio.com/:project/_git/:repo

The repo in this case is vstest. At some point between these builds of vstest: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=6712615 and https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=6738368, the gitHubRepository field of the build stopped being populated. Instead, the azdo repo uri is populated with the github URI. Normally, both repo uris are populated with vstest’s uri. This causes us to fail while trying to calculate the product name.

Now, vstest’s overall Maestro interaction is not good and needs to be fixed:

• Every build is apparently uploaded twice (see darc get-build --repo https://github.com/microsoft/vstest --commit e3ef271ba4d8ef1cda34bfa544e33c350fce622e)
• It claims to upload a merged manifest but the artifact is never available. This causes gather-drop to fail every time:

  Downloading asset assets/manifests/microsoft-vstest/17.4.0-ci/MergedManifest.xml
   Failed to download asset, errors shown below:
     Failed to download https://pkgs.dev.azure.com/dnceng/public/_apis/packaging/feeds/dotnet-tools/nuget/packages/MergedManif/versions/17.4.0/content: Response status code does not indicate success: 404 (Not Found).
     Failed to download https://pkgs.dev.azure.com/dnceng/public/_apis/packaging/feeds/dotnet-tools/nuget/packages/MergedManif/versions/17.4.0/content***: Response status code does not indicate success: 404 (Not Found).
     Failed to download https://pkgs.dev.azure.com/dnceng/public/_apis/packaging/feeds/dotnet-tools/nuget/packages/MergedManif/versions/17.4.0/content***: Response status code does not indicate success: 404 (Not Found).
  

However, I’m not sure whether this failure in particular is their fault. The diffs in vstest are minimal:

PS C:\r\vstest> git diff e3ef271ba4d8ef1cda34bfa544e33c350fce622e 576a7cc1b259976393cf576a6a9c5df967bb2b7d
diff --git a/eng/Version.Details.xml b/eng/Version.Details.xml
index 8d7b5b16..1ebba7cc 100644
--- a/eng/Version.Details.xml
+++ b/eng/Version.Details.xml
@@ -1,9 +1,9 @@
 <?xml version="1.0" encoding="utf-8"?>
 <Dependencies>
   <ProductDependencies>
-    <Dependency Name="Microsoft.Internal.CodeCoverage" Version="17.4.4-beta.22464.2">
+    <Dependency Name="Microsoft.Internal.CodeCoverage" Version="17.4.4">
       <Uri>https://dev.azure.com/devdiv/DevDiv/_git/vs-code-coverage</Uri>
-      <Sha>49eb2f0787808943526445c5ee651845f48ee5ce</Sha>
+      <Sha>a9e0b5811fb30e3fb77a4ea0483de0cc6a209edb</Sha>
     </Dependency>
     <Dependency Name="Microsoft.Diagnostics.NETCore.Client" Version="0.2.0-preview.22424.1">
       <Uri>https://github.com/dotnet/diagnostics</Uri>
diff --git a/eng/Versions.props b/eng/Versions.props
index b33fa208..2d302d04 100644
--- a/eng/Versions.props
+++ b/eng/Versions.props
@@ -82,7 +82,7 @@
          JS etc.) is risky. This can break setup authoring and cause runtime failures in workloads
          where Rolsyn is not installed. -->
     <MicrosoftCodeAnalysisVersion>3.8.0-3.20427.2</MicrosoftCodeAnalysisVersion>
-    <MicrosoftInternalCodeCoverageVersion>17.4.4-beta.22464.2</MicrosoftInternalCodeCoverageVersion>
+    <MicrosoftInternalCodeCoverageVersion>17.4.4</MicrosoftInternalCodeCoverageVersion>
     <MicrosoftDiagnosticsNETCoreClientVersion>0.2.0-preview.22424.1</MicrosoftDiagnosticsNETCoreClientVersion>
     <MicrosoftSourceBuildIntermediatediagnosticsVersion>6.0.0-preview.22424.1</MicrosoftSourceBuildIntermediatediagnosticsVersion>
     <MicrosoftVisualStudioTelemetryVersion>16.5.2</MicrosoftVisualStudioTelemetryVersion>

In addition, the diffs in the pipeline itself (they use classic build defs) did not change between rc2 and rtm (20th and 26th).

My first hunch here is that somehow the test used to determine that a sha is public or not is not working for the microsoft org. IIRC, the github repo uri is populated automatically if it’s not explicitly specified, and it’s populated automatically if the sha of the build can be found anonymously.

[mmitche]

It also didn’t fire for the newest RTM build. My hunch now is that the build failed to lookup the public URI somehow on that particular build and thus didn’t populate the github URI.

So:

• vstest is still populating the URIs incorrectly
• It works if Maestro or the upload task (can’t remember which) correctly identifies that the commit is public.

[mmitche]

/cc @riarenas