Use helix platform variable aliases for macOS ARM64 and x64 queues

[Copilot]

Replace hardcoded macOS queue names with centralized variable aliases from eng/pipelines/helix-platforms.yml, enabling automatic version updates across PR and CI definitions.

This PR updates the default queues for libraries and coreclr PRs to use the latest macOS versions for Sequoia 15.

Changes Made

Pipeline Configuration Files:

• Added helix-platforms.yml import to runtime.yml, coreclr/ci.yml, and libraries/variables.yml at the pipeline level to avoid Azure Pipelines size limits

Helix Platform Definitions (helix-platforms.yml):

• Updated helix_macos_x64_latest from OSX.13.Amd64.Open to OSX.15.Amd64.Open (Sequoia 15)
• Updated helix_macos_x64_latest_internal from OSX.13.Amd64 to OSX.15.Amd64 (Sequoia 15)
• ARM64 uses OSX.26.Arm64.Open (Sequoia 15 with macOS 26.x kernel)
• x64 uses OSX.15.Amd64.Open (Sequoia 15)
• Changed common aliases to use template substitution ${{ variables.* }} for variable definitions

Queue Setup Files:

• installer/helix-queues-setup.yml: Replaced hardcoded OSX queue names with runtime expansion $(helix_macos_arm64) and $(helix_macos_x64)
• libraries/helix-queues-setup.yml: Replaced hardcoded OSX queue names with runtime expansion $(helix_macos_arm64) and $(helix_macos_x64)
• coreclr/templates/helix-queues-setup.yml: Replaced public branch hardcoded queue names with runtime expansion $(helix_macos_arm64) and $(helix_macos_x64) while preserving superpmi-diffs exception (OSX.14.Arm64.Open) and internal queues

Test Changes:

• Temporarily skipped MatchesCodesignOutput test due to macOS 26 codesign behavior change (only hashing __TEXT segment instead of entire file). This test will need to be updated in a follow-up to accommodate the new codesign behavior.

Variable Expansion Strategy

• Variable definitions in helix-platforms.yml use template substitution ${{ variables.* }} for compile-time evaluation
• Variable references in helix-queues-setup.yml files use runtime expansion $(...) for runtime evaluation

Out of Scope

• iOS/tvOS simulator/device queues (unchanged)
• Python scripts (e.g., superpmi_collect_setup.py)
• Older versions remain at their respective macOS versions

Current Variable Resolutions

• helix_macos_arm64 → OSX.26.Arm64.Open (Sequoia 15)
• helix_macos_x64 → OSX.15.Amd64.Open (Sequoia 15)
• helix_macos_arm64_latest_internal → OSX.26.Arm64 (Sequoia 15)
• helix_macos_x64_latest_internal → OSX.15.Amd64 (Sequoia 15)

---

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

[agocke]

@copilot Do you need to import the variables definition file?

[Copilot]

@copilot Do you need to import the variables definition file?

Yes, good catch! Added the import in eng/pipelines/common/variables.yml (commit 65c5bd5). The helix-platforms.yml file wasn't being imported anywhere, so the variables would not have been available. All pipelines (coreclr, libraries, runtime) include common/variables.yml, so they'll now have access to the helix platform variable aliases.

[agocke]

@copilot can you just import the variables in the files that need it, to prevent pipeline template pollution?

[Copilot]

@copilot can you just import the variables in the files that need it, to prevent pipeline template pollution?

Done in commit 363d319. Moved the import from common/variables.yml to the three helix-queues-setup.yml files that actually use the variables (installer, libraries, and coreclr/templates). This prevents polluting the common variables namespace.

[agocke]

@copilot It looks like this commit broke CI -- the runtime pipeline is no longer running

[Copilot]

@copilot It looks like this commit broke CI -- the runtime pipeline is no longer running

Fixed in commit 59982bd. The issue was that I added a variables: section directly in the helix-queues-setup.yml template files, which isn't allowed in Azure Pipelines when templates are used in a jobs context. Moved the helix-platforms.yml import to xplat-setup.yml where variables are properly defined and passed to the job templates.

[agocke]

@copilot it looks like helix-queues-setup takes variables as a parameter. Can we add the variables import there?

[agocke]

@elinor-fung ok this pr is up to date and it does look like there are some failing host tests

[elinor-fung]

The MatchesCodesignOutput tests are failing when validating that the output binary from codesign matches our managed ad-hoc signing. It is only on arm64 binaries - fails on live-built hosts and arm64 binaries from test data, succeeds on x86_x64 binaries from test data. Maybe something changed in codesign in macOS 26? cc @jtschuster if you know of something related

Failed Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.MatchesCodesignOutput(filePath: "/private/tmp/helix/working/BF740AB3/w/9940089F/e/t"···, _: TestArtifact { Location = "/private/tmp/helix/working/BF740AB3/w/9940089F/e/t"···, Name = "MatchesCodesignOutput-apphost" }) [38 ms]
  Error Message:
   System.ArgumentException : CodeDirectory blobs are not equivalent
  Stack Trace:
     at Microsoft.NET.HostModel.MachO.EmbeddedSignatureBlob.AssertEquivalent(EmbeddedSignatureBlob a, EmbeddedSignatureBlob b) in /_/src/installer/managed/Microsoft.NET.HostModel/MachO/BinaryFormat/Blobs/EmbeddedSignatureBlob.cs:line 181
   at Microsoft.NET.HostModel.MachO.MachObjectFile.AssertEquivalent(MachObjectFile a, MachObjectFile b) in /_/src/installer/managed/Microsoft.NET.HostModel/MachO/MachObjectFile.cs:line 275
   at Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.AssertMachFilesAreEquivalent(String codesignedPath, String managedSignedPath, String fileName) in /_/src/installer/tests/Microsoft.NET.HostModel.Tests/MachObjectSigning/SigningTests.cs:line 194
   at Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.MatchesCodesignOutput(String filePath, TestArtifact _) in /_/src/installer/tests/Microsoft.NET.HostModel.Tests/MachObjectSigning/SigningTests.cs:line 101
   at InvokeStub_SigningTests.MatchesCodesignOutput(Object, Span`1)
   at System.Reflection.MethodBaseInvoker.InvokeWithFewArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

[agocke]

I'd like to switch us over to the new queues in the next few days, so can we prioritize investigating these issues?

[jtschuster]

I'm not aware of any new behaviors, but I'm updating my Mac to investigate.

[jtschuster]

It looks like the new behavior of codesign is to only hash the __TEXT segment, whereas it used to hash the entire file. It looks like this doesn't affect whether or not Mac allows the file to be run. We could disable the test to get this in and file an issue for the fix. It may be simple enough for copilot.

[elinor-fung]

It looks like this doesn't affect whether or not Mac allows the file to be run.

Do you know if that is also the case for before macOS 26 - that is, just hashing the __TEXT segment still runs fine on 15 or below?

We could disable the test to get this in and file an issue for the fix. It may be simple enough for copilot.

If yes for the above, that sounds reasonable to me - assuming we basically immediately file the issue and try to (get copilot to) handle it.

[agocke]

@copilot please temporarily skip the following test:

Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.MatchesCodesignOutput

[Copilot]

@copilot please temporarily skip the following test:

Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.Microsoft.NET.HostModel.MachO.CodeSign.Tests.SigningTests.MatchesCodesignOutput
...

Done in commit 5855401. Added Skip attribute to the MatchesCodesignOutput test with a descriptive message explaining it's temporarily disabled due to the macOS 26 codesign behavior change.