[9.0] Update CI OSes

[richlander]

Related:

• Add Azure Linux to regular CI #115415
• Update OS onboarding docs #115501
• [8.0] Update CI OSes #115502

[Copilot]

Pull Request Overview

This PR updates the CI configuration to refresh the list of OS images used in the Helix queues setup, aligning with recent changes in supported OS versions.

• Removed outdated or restructured OS images
• Added new OS definitions (e.g., AzureLinux.3.0)
• Reordered some image entries for clarity

Comments suppressed due to low confidence (2)

eng/pipelines/libraries/helix-queues-setup.yml:56

• [nitpick] The new AzureLinux entry uses 'Ubuntu.2204.Amd64.open' with lowercase 'open' in the tag, which differs from other entries that use 'Open'. Consider standardizing the casing for consistency and clarity.

- (AzureLinux.3.0.Amd64.Open)Ubuntu.2204.Amd64.open@mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-helix-amd64

eng/pipelines/libraries/helix-queues-setup.yml:66

• [nitpick] The re-introduction of the Centos.9 entry here may require verification against the previously removed entry. Confirm that this change is intentional and that it correctly reflects the supported Centos-stream version.

- (Centos.9.Amd64.Open)Ubuntu.2204.Amd64.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream9-helix

[richlander]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

These issues all look existing.

@carlossanlop

[richlander]

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

[richlander]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

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

[jkotas]

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.

[richlander]

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.

[richlander]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

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.

[richlander]

/azp run runtime-libraries-coreclr outerloop-linux

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

/azp run runtime-libraries-coreclr outerloop-linux

[richlander]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[richlander]

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

[richlander]

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

[richlander]

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.

[richlander]

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