Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable building .NET Core osx-arm64 in CI #43187

Merged
merged 6 commits into from Oct 9, 2020

Conversation

sdmaclea
Copy link
Contributor

@sdmaclea sdmaclea commented Oct 8, 2020

Enables building of .NET Core osx-arm64

Fixes #41131

/cc @mangod9

@ghost
Copy link

ghost commented Oct 8, 2020

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

@@ -1,5 +1,10 @@
#!/usr/bin/env bash

if [ "$1" = "OSX" ] && [ "$2" = "arm64" ]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this is a great place to begin doing this. This should probably go in the yaml as it's tied to AzDO pools, and in documentation we should specify it as a dependency for osx-arm64.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the rationale. Isn't this file just for installing dependencies for CI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this just feels like hiding things in scripts. This is not an installation. At least it's not obvious to me that an installation script hardcodes a path to something that's only true in AzDO (for example, what if a customer runs this expecting to brew install the deps in their box).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hoyosjs & I are in disagreement here... Any other opinions... Before we try to drive to consensus?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build step that calls this is called Install Build Dependencies. It seems logical to configure dependencies here too. If we must I can add another configure dependencies step, but it seems overkill.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

azdo seems overly specific. Are you OK with setup-native-dependencies-4ci.sh & Setup Build Dependencies?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose azdo just because it's that: the xcode path for AzDO agents. It's not the same path as helix test agents necessarily or anything (my box doesn't have that path even though I use the same version of XCode now). However, I don't feel too strongly, mostly care about "setup" and "ci/not-local".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be people that run this to help them set native dependencies locally?

Copy link
Contributor Author

@sdmaclea sdmaclea Oct 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't seen any instructions suggesting using this for developer setup.

Edit:
I guess since this is likely temporary I can just make it a separate build step.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added azDO to the CI install-native-dependencies.sh command line and made the xcode-select conditional on the azDO argument. I also added brief header comments.

I initial went down the path of renaming install -> setup, but I felt like it added confusion. setup in my mind doesn't imply install. However setup/configurations is a subset of install. So I reverted it all and went with this approach.

Hope this is a satisfactory compromise.

eng/pipelines/common/xplat-setup.yml Show resolved Hide resolved
@hoyosjs
Copy link
Member

hoyosjs commented Oct 8, 2020

Also unclear if related, somehow we ended with this job:

  - job: installer_coreclr__OSX_arm64_Release
    displayName: Installer Build and Test coreclr  OSX_arm64 Release
    dependsOn:
    - checkout
    - coreclr__product_build_OSX_arm64_release
    - libraries_build_OSX_arm64_Debug

@safern do release tests for installer depend on debug libraries bits?

@hoyosjs
Copy link
Member

hoyosjs commented Oct 8, 2020

The error remaining is just we are missing passing the architecture to the installer part of the build. The autodetection thinks it's x64 (given that's the host's architecture).

@safern
Copy link
Member

safern commented Oct 8, 2020

@safern do release tests for installer depend on debug libraries bits?

In PR some of them do, because we build some flavors of libraries in Debug on PR and Release for CI and official build.

There is a variable that controls this... debugOnPrReleaseOnRolling
.https://github.com/dotnet/runtime/blob/master/eng/pipelines/runtime.yml#L617

@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 9, 2020

I am running an internal build of this here https://dev.azure.com/dnceng/internal/_build/results?buildId=847071&view=results. I suspect I will need to add something additional to publish the new packages, but that could be a subsequent PR.

@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 9, 2020

Looks like the internal build completed fine. Looks to me (a novice) like the osx-arm64 packages are properly publishing.

CI on this PR and the internal run are green. This is ready for a final review.

Copy link
Member

@mangod9 mangod9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for enabling this.

@hoyosjs
Copy link
Member

hoyosjs commented Oct 9, 2020

The Runtime packs look good to me
image The assemblies are crossgen'd and all.

@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 9, 2020

I'm going to merge this. I'll work on a follow up PR to add the crossBuild parameter.

If there is anything else which you would like resolved. Feel free to comment on this or that PR, and I will work to get it resolved.

@sdmaclea sdmaclea merged commit 2a52f75 into dotnet:master Oct 9, 2020
@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 9, 2020

/cc @richlander This should enable nightly runtime osx-arm64 builds.

Enable .NET Core on Apple Silicon automation moved this from In progress to Done Oct 9, 2020
@@ -33,6 +33,7 @@ jobs:
- Linux_arm64
- Linux_musl_arm64
- ${{ if eq(variables['includeOsxOuterloop'], true) }}:
- OSX_arm64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should've caught this... I think we don't have a helix queue setup for OSX_arm64, so I guess this broke the libraries outerloop build. I can fix this in a separate PR and we can enable them once we have a queue for it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we still dont have stable hardware for this we dont expect to enable test runs for osx_arm64 just yet. Can we leave it disabled till we have that?

Copy link
Member

@safern safern Oct 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I created a PR for that: #43242

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool.. thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should've caught this...

@safern Thanks for being genereous, but this was clearly my fault. I forget there are three main pipelines all the time. I get the rolling outerloop and the official build pipeline confused and map them to a single pipeline...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we have so many ymls that it is sometimes hard to get it right and the easier way to add a new flavor is to try and look where we're already building osx_x64 and just add entries for the new platform there, so confusing for all I think 😄

Copy link
Member

@safern safern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This didn't enable mono on that new platform. @akoeplinger @steveisok do we want to do that?

Overall looks good to me. Thanks for doing this @sdmaclea

@dotnet dotnet locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging this pull request may close these issues.

osx-arm64 enable CoreCLR native component builds in CI.
6 participants