Expand osx-arm64 test coverage #44008
Conversation
dotnet-issue-labeler
bot
added
Area-Infrastructure
untriaged
v-wuzhai
force-pushed
the
dev/Jason/Expand-osx-arm64-test-coverage
branch
from
e9eb935 to
5598c42
Compare
|
@MiYanni Is |
|
@MiYanni will be back on Friday. Looking at the logs, I see it ran the tests on osx.13.amd64.open so another change is needed somewhere in here to target the arm64 helix images. I can try to look tomorrow or we can wait for him or if you see where it should get updated, you can try that tonight. |
v-wuzhai
force-pushed
the
dev/Jason/Expand-osx-arm64-test-coverage
branch
from
4dfce23 to
deb027f
Compare
|
It looks like the latest change got us to run the tests on arm64 successfully as far as i can tell. From the results, the most common failure is in R2R and illink tests when downlevel targeting (net5 and net3.1) A lot of these tests use EnvironmentInfo.GetCompatibleRid so I wonder if we should have some special logic there that returns an x64 rid when targeting <netN.0 and the default would be arm64. @agocke @elinor-fung Would ya'll want to keep around the downlevel targeting tests and is my proposal to change GetCompatibleRid reasonable or would you like to just get rid of the 3.1/5.0 targeting tests entirely? Alternatively, we could just modify the tests to return when run on arm64. |
|
cc @dotnet/illink for whether 3.1/5.0 targeting tests are still valuable If we do keep them, I'd suggest skipping downlevel on arm64 by switching the tests from |
…he minimum version to net6.0
|
We can get rid of 3/5 tests |
|
@v-wuzhai see agocke's comment above. Can you go through the tests that are failing on 3.1 and 5.0 in this PR and simply remove that coverage? Thanks. |
…dev/Jason/Expand-osx-arm64-test-coverage
…dev/Jason/Expand-osx-arm64-test-coverage
|
It seems that the value of helixTargetQueue cannot be overridden.
So I customized a variable helixQueue as a specific queue name, and added a script step to dynamically set the CustomHelixTargetQueue variable based on the value of runtimeIdentifier, so that we can see the returned queue value in the pipeline for debugging purposes.
|
|
Thanks for trying out my proposal and coming up with an alternative. Let's just wait until next week when @MiYanni is back as he's the real expert here and maybe he'll have a better suggestion. Your solution seems reasonable to me though. |
… Arm64 specific TestBuild run in both the PR and Official pipelines.
| @@ -291,6 +291,19 @@ extends: | |||
| publishArgument: $(_publishArgument) | |||
| officialBuildProperties: $(_officialBuildProperties) | |||
| runTests: false | |||
| ### ARM64 TESTBUILD ### | |||
| - ${{ if or(eq(parameters.runTestBuild, true), eq(variables['Build.Reason'], 'PullRequest')) }}: | |||
There was a problem hiding this comment.
This will only run on internal PRs or when runTestBuild checkbox is checked when running the build manually.
| name: Azure Pipelines | ||
| vmImage: macOS-latest | ||
| os: macOS | ||
| helixTargetQueue: osx.13.arm64 |
There was a problem hiding this comment.
helixTargetQueue is specified at the pipeline-level, because the pipelines run in different environments. The external (PR) pipeline uses Helix queues with .open on the end of the name. For the internal (Official) pipeline, we use the internal queues which do not have .open in the name.
|
The Arm64 leg for macOS is appropriately appearing after my changes: |
| macOSJobParameterSets: | ||
| - categoryName: TestBuild | ||
| buildArchitecture: arm64 | ||
| runtimeIdentifier: osx-arm64 |
There was a problem hiding this comment.
Defining macOSJobParameterSets here overrides the default in sdk-job-matrix.yml. Since we only specify a single entry, it will only create a single job. This is also how the design of the Official pipeline works; it defines a bunch of specific job sets to do the official builds.
|
@MiYanni Thank you for your additions and optimizations. These changes look good to me. |
fixes #43916