Switch default CI focus to osx-arm64 for CoreCLR PRs

[Copilot]

Apple Silicon (ARM64) is now the primary macOS architecture. This PR swaps osx-x64 and osx-arm64 in the default CI matrix so that osx-arm64 runs libraries debug tests by default, while osx-x64 falls back to priority 0 tests only.

Changes to eng/pipelines/runtime.yml

Build jobs:

• CoreCLR_Libraries with libs.tests: osx_x64 → osx_arm64
• CoreCLR_Libraries without tests (installer deps): osx_arm64 → osx_x64
• Libraries_CheckedCoreCLR with libs.tests: osx_x64 → osx_arm64
• Libraries_CheckedCoreCLR without tests: osx_arm64 → osx_x64

Test execution jobs:

• CoreCLR runtime tests main job: osx_x64 → osx_arm64
• Libraries debug test execution: osx_x64 → osx_arm64

Dependency updates:

• Installer_Build_And_Test artifact dependencies swapped to match new build configurations
• osx_x64 condition updated from AppleSilicon trigger to standard coreclr change detection

The platform matrix comment table updated to reflect osx-arm64 in the debug test configuration (using lowercase RID format for consistency).

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Switch Default CI Focus to osx-arm64 for CoreCLR PRs</issue_title>
<issue_description>In the default CI set that runs automatically when a change is made to src/coreclr, only priority 0 test legs are executed for osx-arm64. Meanwhile, for osx-x64, the libraries debug tests are run by default alongside the priority 0 tests. Given that Apple has moved to ARM64 (Apple Silicon) as the primary architecture, it seems logical to prioritize osx-arm64 in the default CI, rather than osx-x64.

Currently, we can manually trigger the osx-arm64 libraries debug tests if needed, but they are not part of the automatic/default test set.

If expanding the CI set for osx-arm64 leads to longer test cycles, it may be worth considering the trade-off between testing time and coverage, or potentially rebalancing the priority of osx-x64 tests.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Switch Default CI Focus to osx-arm64 for CoreCLR PRs #108570

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[richlander]

Interesting. This seems like a change we should have made a while ago! Nice catch/change.

[Copilot]

Pull request overview

This PR switches the default CI focus from osx-x64 to osx-arm64 for CoreCLR PRs, reflecting Apple Silicon (ARM64) as the primary macOS architecture. The changes swap platform configurations so that osx-arm64 now runs libraries debug tests by default, while osx-x64 falls back to priority 0 tests only.

Key Changes:

• Swapped osx_x64 and osx_arm64 in build job platform matrices for CoreCLR_Libraries and Libraries_CheckedCoreCLR configurations
• Updated CoreCLR runtime test execution and libraries test execution jobs to prioritize osx-arm64
• Changed condition triggers for osx_x64 jobs from coreclr_AppleSilicon to standard coreclr change detection

[am11]

We should delete this line

runtime/eng/pipelines/common/platform-matrix.yml

Line 854 in 192bdc3

crossBuild: true

so osx-arm64 doesn't get -cross on build line.

Interesting. This seems like a change we should have made a while ago! Nice catch/change.

One of the reason was Azure DevOps wasn't providing Microsoft-Hosted macOS arm64 images https://learn.microsoft.com/azure/devops/release-notes/roadmap/macos-agents-apple-silicon (while GitHub was). This changed a few weeks ago when they started previewing arm64 images: https://devblogs.microsoft.com/devops/upcoming-updates-for-azure-pipelines-agents-images/#mac-os.

cc @steveisok

[jkotas]

If the runtime is complete broken on osx-x64 (e.g. "Hello world" does not work), where is the first place we are going to find out after this change?

(just asking to have a better idea how things are setup)

[am11]

We should delete this line

cherry-pick am11@63d4ae8, so we can be sure it's picking up the correct machine.

[agocke]

Actually @am11 this is just testing, not build, so I don't think this is necessary yet. When we start using macos ARM64 machines for build, then it will be.

[am11]

@agocke, it is updating the build+test jobs. Those build jobs should not use -cross arg when host==target because with -cross arg, it picks up the toolchain / framework components differently (and skips some steps). It basically defeats the purpose and does not resolve #108570.

[agocke]

-cross arg when host==target because with -cross arg , it picks up the toolchain / framework components differently (and skips some steps)

Interesting, I didn't know that. Lemme look closer at the proposed change.

[agocke]

It looks like this change is too broad -- it's affecting normal builds, not just Helix builds.

[agocke]

OK, this change passes without changing -cross. I don't see any places where we need to adjust the cross build inside helix.

[am11]

I'm not sure if helix had any role here. As explained above, with -cross, the build uses cached cmake check and assumes "I can't treat this build machine as target". We can potentially break build for native machine (people using osx-arm64 are not passing -cross for native arch build) while CI will always appear green.

The real error was:

  [ 17%] Building CXX object md/datasource/CMakeFiles/mddatasource_dbi.dir/targettypes.cpp.o
  /Users/runner/work/1/s/src/coreclr/pal/src/synchmgr/synchmanager.cpp:3573:6: error: "Don't know how to get hi-res current time on this platform"
  [ 17%] Building CXX object Corehost.Static/hostmisc/CMakeFiles/hostmisc_public.dir/trace.cpp.o
   3573 |     #error "Don't know how to get hi-res current time on this platform"
        |      ^
  [ 17%] Building CXX object md/enc/CMakeFiles/mdruntimerw-dbi.dir/peparse.cpp.o
  1 error generated.

and it is failing because the cmake detection was failing; something in osx-arm64 machine is not "normal" which we needed to figure out and fix before merging. To do that, we get the cmake log file and investigate.