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 Mono build in CI #1934

Merged
merged 56 commits into from
Jan 22, 2020
Merged

Enable Mono build in CI #1934

merged 56 commits into from
Jan 22, 2020

Conversation

akoeplinger
Copy link
Member

@akoeplinger akoeplinger commented Jan 20, 2020

Fixes #1932

@akoeplinger akoeplinger marked this pull request as ready for review January 21, 2020 20:51
# alpine coreclr cmake errors on newer builds
${{ if eq(parameters.runtimeFlavor, 'mono') }}:
image: alpine-3.9-WithNode-0fc54a3-20200121145958
${{ if ne(parameters.runtimeFlavor, 'mono') }}:
Copy link
Member

Choose a reason for hiding this comment

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

Can we open an issue for this and investigate? We should try to be consistent with the docker images we build with.

Also, instead of using != mono I would change this to == coreclr so that it is easier to read.

Suggested change
${{ if ne(parameters.runtimeFlavor, 'mono') }}:
${{ if eq(parameters.runtimeFlavor, 'coreclr') }}:

Copy link
Member

Choose a reason for hiding this comment

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

Yes I'll file an issue for that as it's highly concerning. Just hadn't had time yet.

@@ -50,6 +50,13 @@ jobs:
- name: ROOTFS_DIR
value: ${{ parameters.jobParameters.crossrootfsDir }}

- ${{ if ne(parameters.jobParameters.runtimeFlavor, '') }}:
Copy link
Member

Choose a reason for hiding this comment

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

runtimeFlavor should always be passed down as a jobParameter since platform-matrix is passing it down always, so no need to have this empty check any more.

@@ -80,7 +81,7 @@ jobs:

- ${{ if eq(parameters.osGroup, 'OSX') }}:
- script: |
brew install pkgconfig icu4c openssl
brew install pkgconfig icu4c openssl autoconf automake libtool pkg-config python3
Copy link
Member

Choose a reason for hiding this comment

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

why do we need these? This is building libraries, not mono.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

We probably don't. I was just adding dependencies where it seemed fit and didn't notice this is only used for libraries build.

- template: xplat-pipeline-job.yml
parameters:
buildConfig: ${{ parameters.buildConfig }}
_BuildConfig: ${{ parameters.buildConfig }}
Copy link
Member

Choose a reason for hiding this comment

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

This parameter is not used in mono/xplat-pipeline-job.yml, not even defined as a parameter in the template.

osSubgroup: ${{ parameters.osSubgroup }}
helixType: 'build/product/'
enableMicrobuild: true
stagedBuild: ${{ parameters.stagedBuild }}
Copy link
Member

Choose a reason for hiding this comment

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

stagedBuild is not necessary at all, right?

container: ${{ parameters.container }}
condition: ${{ parameters.condition }}
dependsOn:
- ${{ if ne(parameters.stagedBuild, true) }}:
Copy link
Member

@safern safern Jan 22, 2020

Choose a reason for hiding this comment

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

I don't think this will ever be true.

Copy link
Member

Choose a reason for hiding this comment

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

Right, this is a copy from coreclr. I assumed it will always be true but didn't change it as this would need to be cleaned-up in coreclr as well and I wanted to minimize risk.

@@ -0,0 +1,111 @@
parameters:
Copy link
Member

Choose a reason for hiding this comment

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

This seems very similar to coreclr's xplat-job template, can we share them? Maybe move coreclr's to common.

Copy link
Member

Choose a reason for hiding this comment

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

See answer below.

Copy link
Member

Choose a reason for hiding this comment

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

@@ -0,0 +1,67 @@
parameters:
Copy link
Member

Choose a reason for hiding this comment

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

Instead of introducing another template, can we use coreclr's and move it to common?

Copy link
Member

@ViktorHofer ViktorHofer Jan 22, 2020

Choose a reason for hiding this comment

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

I tried to share them but there were too many differences in paths which weren't easy to fix. We should file an issue to consolidate runtime (coreclr & mono) infrastructure files where possible (not just yml).

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good. Let's please open that issue as it seems overkill to have this duplicate templates (maintaining multiple yml files is painful).

Copy link
Member

Choose a reason for hiding this comment

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

- eng/pipelines/libraries/*
- subset: mono
include:
- src/libraries/System.Private.CoreLib/*
Copy link
Member

Choose a reason for hiding this comment

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

Does mono depend on the native libraries? src/libraries/Native?

Copy link
Member

Choose a reason for hiding this comment

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

for building mono? I don't think so. cc @akoeplinger

Copy link
Member Author

Choose a reason for hiding this comment

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

The Mono build doesn't depend on src/libraries/Native.

Copy link
Member

Choose a reason for hiding this comment

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

but what about the tests?

Copy link
Member Author

Choose a reason for hiding this comment

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

We'll enable Mono runtime tests at a later point so that's not an issue for now.


<!-- Set default Configuration and Platform -->
<PropertyGroup>
<OSGroup Condition="'$(OSGroup)' == '' and '$([MSBuild]::IsOSPlatform(Windows))' == 'true'">Windows_NT</OSGroup>
Copy link
Member

Choose a reason for hiding this comment

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

Can this instead be shared by libraries, coreclr and mono?

Copy link
Member

Choose a reason for hiding this comment

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

not until we have merged @Anipik's configuration system PR.


<PropertyGroup>
<LangVersion>8.0</LangVersion>
<UseSharedCompilation>true</UseSharedCompilation>
Copy link
Member

Choose a reason for hiding this comment

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

Aren't this properties defined in the root, Directory.Build.props? Should we instead put them there?

Copy link
Member

Choose a reason for hiding this comment

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

I already removed bunch of duplicate properties, I don't plan to remove more as part of this PR. I have an open PR for the managed side of coreclr in which I will include changes for mono as well.

testScope: innerloop
liveRuntimeBuildConfig: release
dependsOnTestBuildConfiguration: ${{ variables.debugOnPrReleaseOnRolling }}
dependsOnTestArchitecture: x64
Copy link
Member

Choose a reason for hiding this comment

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

Should this be conditioned to when mono or libraries is changed?

Copy link
Member

Choose a reason for hiding this comment

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

I don't think we want to run this tests when only coreclr is touched or when only installer is touched. That said, I believe the build of mono release should also have the same condition as this step.

@akoeplinger
Copy link
Member Author

@safern thanks for the review, I filed an issue to address the review feedback in a follow-up PR as we need to get this PR in: #2026

@akoeplinger akoeplinger merged commit 6eb3edf into master Jan 22, 2020
@akoeplinger akoeplinger deleted the enable-mono-ci branch January 22, 2020 20:20
ViktorHofer added a commit that referenced this pull request Jan 23, 2020
* Address follow-up feedback from #1934

* Remove whitespaces
akoeplinger added a commit to akoeplinger/runtime that referenced this pull request Jan 23, 2020
Follow-up to dotnet#1934

Also disables one test that seems to be flaky on Mono.
akoeplinger added a commit that referenced this pull request Jan 24, 2020
Follow-up to #1934

Also disables one test that seems to be flaky on Mono.
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mono release build produces Debug System.Private.CoreLib
4 participants