/azp run runtime-libraries-coreclr outerloop-linux

These issues all look existing.

@carlossanlop

I initially moved the Alpine build to Alpine 3.22, which pulls in LLVM 20. Lots of breaks. We made a bunch of changes for LLVM 20 in main that don't exist in this branch. We want to avoid doing that. That just means we'll never be able to move this branch to usemcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.22-amd64. That's not a problem. I just want to document it.

release/8.0 doesn't have this problem. It doesn't have a separate ad-hoc Alpine build in the same way. That must have started with .NET 9.

• https://github.com/dotnet/runtime/pull/115503/files#diff-4a6db477eddd66599614e0f5e26b2639059b6ff777cc975c02c5a72866ff55dcR69
• Support building the repo with clang 20 #109756
• https://alpinelinux.org/posts/Alpine-3.22.0-released.html (LLVM 20)
• https://alpinelinux.org/posts/Alpine-3.21.0-released.html (LLVM 19)

@jkoritzinsky

/azp run runtime-extra-platforms

Looks like everything but baseservices-exception is known. Also looks like the Helix run failed so I'm having trouble finding good logs.

runtime-extra-platforms linux_musl-x64 Release Libraries_Release_CoreCLR failure looks related.

From https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1061251/logs/425:

2025-06-06T21:25:05.7891516Z /__w/1/s/.packages/microsoft.dotnet.helix.sdk/9.0.0-beta.25255.5/tools/Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(19,5): error : You must specify at least one target queue to send a job to helix. Use the HelixTargetQueues property or HelixTargetQueue items. [/__w/1/s/src/libraries/sendtohelixhelp.proj]
2025-06-06T21:25:05.7947660Z ##[error].packages/microsoft.dotnet.helix.sdk/9.0.0-beta.25255.5/tools/Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(19,5): error : (NETCORE_ENGINEERING_TELEMETRY=Build) You must specify at least one target queue to send a job to helix. Use the HelixTargetQueues property or HelixTargetQueue items.

Yes. I changed the condition for Linux-musl and it became inconsistent with some higher-level part of the build. The old model was to test old and new Alpine versions. I don't think we need to do that. Newest is good enough. If we start seeing customer-reported regressions on Alpine 3.19 when we're only testing Alpine 3.22, then we can bring back the old model. I don't think that will happen.

The thing with Alpine is that the vast majority of our users are going to come from the -alpine floating tag. We control that and have the responsibility for high quality when we flip to the floating tag from Alpine 3.21 to 3.22. We make that change one month after our -alpine3.22 images have been available in main branch. Our quality efforts for Alpine should be focused on that scenario.

/azp run runtime-libraries-coreclr outerloop-linux

/azp run runtime-extra-platforms

Mariner 2.0 was in the wrong place. It needs to be in a place where a single line can be deleted as the total change when we remove it for EOL.

/azp run runtime-libraries-coreclr outerloop-linux

/azp run runtime-extra-platforms

/azp run runtime-libraries-coreclr outerloop-linux

/azp run runtime-extra-platforms

There is one extra platforms failure for Linux in scope to consider, on Ubuntu 22.04. I believe there is something related on main.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1081485&view=logs&j=f34c4883-3ffa-561e-aa56-47727d75db21&t=94086b59-3b57-5d7f-6f81-edbeaf0f6cce

  Discovering: System.Diagnostics.Process.Tests (method display = ClassAndMethod, method display options = None)
  Discovered:  System.Diagnostics.Process.Tests (found 263 of 324 test cases)
  Starting:    System.Diagnostics.Process.Tests (parallel test collections = on [2 threads], stop on fail = off)
    System.Diagnostics.Tests.ProcessThreadTests.TestStartTimeProperty [FAIL]
      Assert.Single() Failure: The collection did not contain any matching items
      Expected:   (predicate expression)
      Collection: [System.Diagnostics.ProcessThread, System.Diagnostics.ProcessThread, System.Diagnostics.ProcessThread, System.Diagnostics.ProcessThread, System.Diagnostics.ProcessThread, ···]
      Stack Trace:
        /_/src/libraries/System.Diagnostics.Process/tests/ProcessThreadTests.cs(156,0): at System.Diagnostics.Tests.ProcessThreadTests.<>c__DisplayClass4_0.<TestStartTimeProperty>b__0()
        /_/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs(179,0): at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
        --- End of stack trace from previous location ---
        /_/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs(203,0): at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
        /_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs(2342,0): at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
        --- End of stack trace from previous location ---
        /_/src/libraries/System.Diagnostics.Process/tests/ProcessThreadTests.cs(149,0): at System.Diagnostics.Tests.ProcessThreadTests.TestStartTimeProperty()
        --- End of stack trace from previous location ---
  Finished:    System.Diagnostics.Process.Tests

Known issues:

• ProcessThreadTests.TestStartTimeProperty failure in CI #105526
• [outerloop] Overflow in osx arm64 in System.Numerics.Tests.GetBitLengthTests.RunGetBitLengthTestsLarge #111814 (except on Linux; also just saw it on main)
• possible checked CLR inefficiency with very large arrays #98964

After consultation and collaborative investigation, we've concluded that the failures we're seeing are the same as in the rolling build for the branch. Safe to merge.

Applied service-approved label. We use tell mode for these changes.