CI matrix change: Add OSX 12 arm

[aik-jahoda]

Changes in CI matrix:

OS	What to do	Notes
macOS 12.00 arm	Scout it (at least)

part of #57947

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

What is 1500? I assumed that on Arm64, macOS followed the same version numbering -- ie macOS 11 or macOS12. Is that not right?

[aik-jahoda]

Yeah, it is mistake, it should be 1200

[danmoseley]

Just curious, how can I tell this is libraries tests, as opposed eg to CLR tests ? It's not clear to me - I'm not familiar with how this works.

[aik-jahoda]

Ad far as I understand
CLR: eng/pipelines/coreclr/templates/helix-queues-setup.yml
Libs: eng/pipelines/libraries/helix-queues-setup.yml

But it is still black box for me how it is orchestrated.

@ViktorHofer is there any docs available?

[steveisok]

This file associates the queue to platform. To see if it runs, you'll have to check the runtime ymls to see if the platform is defined. A quick spot check looks like osx-arm64 is defined only for the runtime tests.

Actually, I stand corrected. It's in runtime-staging. It looks like it's only configured for the rolling build.

[aik-jahoda]

@ViktorHofer, @danmoseley, all test passes, we can add this queue once we have more resources on Helix side.

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Changes in CI matrix:

OS	What to do	Notes
macOS 12.00 arm	Scout it (at least)

part of #57947

Author:	aik-jahoda
Assignees:	-
Labels:	area-Infrastructure
Milestone:	-

[ViktorHofer]

I didn't check the yml. Does this added queue only run as part of a rolling build? If so, can you please queue up a build with your changes to make sure that the changes work as expected?

[steveisok]

I didn't check the yml. Does this added queue only run as part of a rolling build? If so, can you please queue up a build with your changes to make sure that the changes work as expected?

Looks to only run on the rolling build

runtime/eng/pipelines/runtime-staging.yml

Line 497 in 8bba6fb

- ${{ if eq(variables['isFullMatrix'], true) }}:

[aik-jahoda]

We are waiting for available HW in the CI queue.

[karelz]

Update: Last info from infra team is that we are blocked on HW availability: https://github.com/dotnet/core-eng/issues/14309#issuecomment-946909143
cc @ericstj

[karelz]

@ericstj whom should we reassign it to, to track the new HW availability and then merge?

[ericstj]

Looks like https://github.com/dotnet/core-eng/issues/13921 tracks availability. @aik-jahoda, do we have a recent update? Looks like the last info was 1.5 months ago, it's possible things have changed. Perhaps @MattGal or @ilyas1974 might know.

If not, then I'd suggest just closing this PR and making sure we have an issue filed under milestone 7.0.0 tracking adding this back when resources are available. CC @agocke

[MattGal]

Looks like dotnet/core-eng#13921 tracks availability. @aik-jahoda, do we have a recent update? Looks like the last info was 1.5 months ago, it's possible things have changed. Perhaps @MattGal or @ilyas1974 might know.

If not, then I'd suggest just closing this PR and making sure we have an issue filed under milestone 7.0.0 tracking adding this back when resources are available. CC @agocke

Looks like we've got about 10 machines on osx.1200.arm64 and 57 on osx.1200.arm64.open ready for your usage now, so please give it a shot and let us know how it goes.

Right now, usage is very light but if a bunch of teams migrate stuff there at once (especially if a lot of the work crashes and has to upload dumps) we may find this to be insufficient, but right now the queues are practically idle so party on, and let me know (or the FR teams channel) if you hit any issues.

[danmoseley]

@AaronRobinsonMSFT any thoughts about this one?

 Interop/DllImportAttribute/DllImportPath/DllImportPathTest/DllImportPathTest.sh [Details] [History] [Artifacts]
Exception Message
Return code:      1
Raw output file:      /tmp/helix/working/B43009A2/w/B2050A13/uploads/Reports/Interop.DllImportAttribute/DllImportPath/DllImportPathTest/DllImportPathTest.output.txt
Raw output:
BEGIN EXECUTION
/tmp/helix/working/B43009A2/p/corerun -p System.Reflection.Metadata.MetadataUpdater.IsSupported=false DllImportPathTest.dll ''
System.DllNotFoundException: Unable to load shared library 'MovedNativeLib' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libMovedNativeLib, 0x0001): tried: 'libMovedNativeLib' (no such file), '/usr/local/lib/libMovedNativeLib' (no such file), '/usr/lib/libMovedNativeLib' (no such file), '/private/tmp/helix/working/B43009A2/w/B2050A13/e/Interop/DllImportAttribute/DllImportPath/DllImportPathTest/libMovedNativeLib' (no such file), '/usr/local/lib/libMovedNativeLib' (no such file), '/usr/lib/libMovedNativeLib' (no such file)
   at Test.GetZero_PathEnv()
   at Test.Main(String[] args)
Expected: 100
Actual: 101
END EXECUTION - FAILED
Test Harness Exitcode is : 1
To run the test:
> set CORE_ROOT=/tmp/helix/working/B43009A2/p
> /private/tmp/helix/working/B43009A2/w/B2050A13/e/Interop/DllImportAttribute/DllImportPath/DllImportPathTest/DllImportPathTest.sh
Expected: True
Actual:   False

[danmoseley]

Looks like that's the only failure on macOS 12 ARM. There's also a crash in Mono but on x64.

[AaronRobinsonMSFT]

@danmoseley I've no idea on this one. I don't know of any work in this product area recently so will assume it is either something flakey on the OS side or perhaps something in the test revamp that has been going on. This test does have special scripting logic so it is possible some disturbance was introduced. Any thoughts on the above @jkoritzinsky?

[agocke]

This is obsolete now