Update branding to 3.1.12

[aik-jahoda]

No description provided.

[hoyosjs]

@garath The last patch was where I fixed all the MyGet uses and put in the work around for BuildTools, but the legacy feed seems to have some issues in indexing. Do you have any ideas of what might be causing the issue?

Running: dotnet restore /nologo /verbosity:minimal /clp:Summary /nodeReuse:false          /p:PortableBuild=true /maxcpucount /p:IncludeRestoreOnlyProjects=true /p:ArcadeBuild=true          F:\workspace\_work\1\s\src\build.proj          /flp:Verbosity=normal;LogFile="F:\workspace\_work\1\s\bin\Logs\System.Private.CoreLib_Windows_NT__x64__Debug.log" /flp1:WarningsOnly;LogFile="F:\workspace\_work\1\s\bin\Logs\System.Private.CoreLib_Windows_NT__x64__Debug.wrn" /flp2:ErrorsOnly;LogFile="F:\workspace\_work\1\s\bin\Logs\System.Private.CoreLib_Windows_NT__x64__Debug.err" /p:__BuildOS=Windows_NT /p:__BuildType=Debug /p:__BuildArch=x64 /p:RestoreDuringBuild=true   /p:BuildManagedTools=true     /p:ContinuousIntegrationBuild=true
  Restore completed in 34.04 ms for F:\workspace\_work\1\s\src\build.proj.
  Restore completed in 487.79 ms for F:\workspace\_work\1\s\src\System.Private.CoreLib\System.Private.CoreLib.csproj.
F:\workspace\_work\1\s\.dotnet\sdk\3.1.100\NuGet.targets(123,5): error : Unable to load the service index for source https://dotnetmygetlegacy.blob.core.windows.net/dotnet-core/index.json [F:\workspace\_work\1\s\src\build.proj]
F:\workspace\_work\1\s\.dotnet\sdk\3.1.100\NuGet.targets(123,5): error :       https://api.nuget.org/v3/index.json. [F:\workspace\_work\1\s\src\build.proj]
F:\workspace\_work\1\s\.dotnet\sdk\3.1.100\NuGet.targets(123,5): error :   Response status code does not indicate success: 400 (Bad Request). [F:\workspace\_work\1\s\src\build.proj]

[garath]

but the legacy feed seems to have some issues in indexing. Do you have any ideas of what might be causing the issue?

Nothing jumps to mind, but I'll dig into it in the morning. Do you have a feel for how often it happens? Is it always a HTTP 400 error, or are there others?

[hoyosjs]

Dismiss that... I should've tried building with a binlog. The issue was obvious when looking at the formatted exception. Sorry for the ping.

[hoyosjs]

The failures in this actually like things in the product. Given this has no product changes, I'm skeptic. The regex is a very early crash - it doesn't even generate a dump.

[hoyosjs]

@danmosemsft @jkotas Do you know of any failure in System.IO.FileSystem.Tests in 3.1?

I am seeing this in linux, both with CrossGen and non-CrossGen:

System.IO.Tests.File_GetSetTimes.SetDateTimeMax [FAIL]
      Assert.Equal() Failure
      Expected: 9999-04-11T23:47:17.0210000Z
      Actual:   2446-05-10T22:38:55.0000000Z
      Stack Trace:
        /_/src/System.IO.FileSystem/tests/File/GetSetTimes.cs(162,0): at System.IO.Tests.File_GetSetTimes.SetDateTimeMax()

[jkotas]

See dotnet/runtime#43166

[jkotas]

We should disable the test like in dotnet/runtime master (https://github.com/dotnet/runtime/pull/43178/files)

[wtgodbe]

I think I've disabled the failing test (coreclr 3.1 infra has mostly escaped from my memory): e945c8a

[wtgodbe]

Another test failure in System.Text.RegularExpressions.Tests. I'm pretty sure this one has been around for a while - I'm inclined to just merge this as-is since the failure is unrelated.