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

Add support for building S.P.CoreLib in a separate job #34166

Merged
merged 31 commits into from
Apr 2, 2020

Conversation

mangod9
Copy link
Member

@mangod9 mangod9 commented Mar 26, 2020

WIP to add support to build System.Private.CoreLib separately so coreclr and libraries builds can run in parallel.

@mangod9 mangod9 added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) area-Infrastructure-coreclr labels Mar 26, 2020
@dnfclas
Copy link

dnfclas commented Mar 26, 2020

CLA assistant check
All CLA requirements met.

@jkoritzinsky
Copy link
Member

It looks like we're missing a step to upload the intermediate artifacts so they can get pulled down by later jobs, so we should make sure we add that step.

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 also needs to be done in runtime-official.yml

eng/pipelines/coreclr/templates/build-corelib-job.yml Outdated Show resolved Hide resolved
eng/pipelines/coreclr/templates/build-corelib-job.yml Outdated Show resolved Hide resolved
eng/pipelines/coreclr/templates/build-corelib-job.yml Outdated Show resolved Hide resolved
eng/pipelines/coreclr/templates/build-corelib-job.yml Outdated Show resolved Hide resolved
eng/pipelines/runtime.yml Show resolved Hide resolved
Removing compilerName parameter and renaming display names
@mangod9 mangod9 changed the title Add support for building S.P.CoreLib in a separate job [WIP] Add support for building S.P.CoreLib in a separate job Mar 27, 2020
@trylek
Copy link
Member

trylek commented Mar 27, 2020

Thanks Manish, you're making great progress here. As I see it based on our offline chat, as next step I would create another template, build-coreclr-job.yml, to basically contain (build-job.yml minus build-corelib-job.yml starting with corelib download from a previous corelib job) and change build-job.yml to just call these two templates. After that we can modify the template build-coreclr-and-libraries-job and adjust runtime and runtime-official as you've already started doing. As usual, we'll see what happens with the perf job that is somewhat special but I believe this should fix 90% of the existing pipelines.

@trylek
Copy link
Member

trylek commented Mar 27, 2020

Hmm, you may be right that it's an overshoot to create yet another template and we can just "subtract" build-corelib-job from build-job. The only downside is that we need to audit all places in our pipelines calling build-job and update them accordingly. Keeping build-job as a wrapper for build-corelib-job followed by build-coreclr-job was supposed to maintain "backwards compatibility" during the transition.

Keeping the download of corelib artifacts to check if just corelib is sufficient to build libraires.
@akoeplinger
Copy link
Member

How hard would it be to extract Mono CoreLib too as part of this? It already builds completely independent from the Mono runtime so should just need .yml/.proj changes.

src/libraries/tests.proj Outdated Show resolved Hide resolved
@safern
Copy link
Member

safern commented Apr 1, 2020

@ViktorHofer might have insights as well as he has been working on re-shuffling pieces to be able to restore ref and src projects as part of the libraries build.

Copy link
Member

@trylek trylek left a comment

Choose a reason for hiding this comment

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

Looks great to me modulo Santi's remarks, thanks so much Manish for pulling this off!

eng/pipelines/coreclr/templates/build-corelib-job.yml Outdated Show resolved Hide resolved
eng/pipelines/libraries/base-job.yml Show resolved Hide resolved
@mangod9
Copy link
Member Author

mangod9 commented Apr 1, 2020

How hard would it be to extract Mono CoreLib too as part of this? It already builds completely independent from the Mono runtime so should just need .yml/.proj changes.

the main reasoning for this is to improve build times, it appears Mono builds are fairly fast -- would this help ?

@safern
Copy link
Member

safern commented Apr 1, 2020

the main reasoning for this is to improve build times, it appears Mono builds are fairly fast -- would this help ?

Yeah, mono builds are fairly fast, I think the downsides of uploading/downloading assets and such, might not give us much gain, plus the only legs that build against mono are the iOS at the moment.

@trylek
Copy link
Member

trylek commented Apr 1, 2020

I guess that, even with Mono build being fast, there would be some value in having both runtime builds behave the same including separate CoreLib build. Having said that, I believe that by all means this is worth a separate PR and perhaps even a separate design discussion.

- ${{ if and(eq(parameters.runtimeFlavor, 'coreclr'), eq(parameters.testScope, '')) }}:
- ${{ format('coreclr_corelib_build_{0}{1}_{2}_{3}', parameters.osGroup, parameters.osSubgroup, parameters.archType, parameters.liveRuntimeBuildConfig) }}
- ${{ if or(ne(parameters.runtimeFlavor, 'coreclr'), ne(parameters.testScope, '')) }}:
- ${{ format('{0}_product_build_{1}{2}_{3}_{4}', parameters.runtimeFlavor, parameters.osGroup, parameters.osSubgroup, parameters.archType, parameters.liveRuntimeBuildConfig) }}
- ${{ if eq(parameters.osGroup, 'WebAssembly') }}:
- ${{ format('{0}_product_build_{1}{2}_{3}_{4}', parameters.runtimeFlavor, 'linux', parameters.osSubgroup, 'x64', parameters.liveRuntimeBuildConfig) }}
Copy link
Member

Choose a reason for hiding this comment

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

WebAssembly is still depending on the full coreclr build. We should be able to also make it build against corelib by doing something similare as above.

Copy link
Member Author

Choose a reason for hiding this comment

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

yup will do as a subsequent PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

these are now included in this PR: #34460

eng/pipelines/coreclr/ci.yml Outdated Show resolved Hide resolved
eng/pipelines/runtime.yml Outdated Show resolved Hide resolved
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.

My last two comments are important to be addressed as part of this PR. After that, feel free to merge.

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.

Thanks for working on this 😄

@@ -78,7 +78,8 @@
Projects="@(Project)"
Properties="TargetFramework=$(BuildTargetFramework);%(Project.AdditionalProperties)"
BuildInParallel="true"
ContinueOnError="ErrorAndStop" />
ContinueOnError="ErrorAndStop"
Condition="'$(SkipBuildProjects)' != 'true'"/>
Copy link
Member

Choose a reason for hiding this comment

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

What about instead directly invoking pretest.proj from CI and passing in the target that you care about?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah that makes sense. We could just call change the current call to /t: GenerateTestSharedFrameworkDepsFile.

Maybe on a follow-up PR so that he can merge?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I'm fine with that.

Copy link
Member Author

Choose a reason for hiding this comment

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

ok will do on next PR.

@@ -41,8 +41,19 @@
<Import Project="$(RepositoryEngineeringDir)coverage.targets" Condition="'$(EnableCoverageSupport)' == 'true'" />
<Import Sdk="Microsoft.NET.Sdk" Project="Sdk.targets" />

<ItemGroup>
<SetupProjects Include="$(MSBuildThisFileDirectory)restore\runtime\runtime.depproj" />
Copy link
Member

Choose a reason for hiding this comment

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

This is CI only, why not directly invoking the runtime.depproj before tests.proj?

Copy link
Member Author

Choose a reason for hiding this comment

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

one issue is that build parallelization might cause a race, pretest.proj has to complete before tests start to build, since pretest generates the dep file to ensure testhost is setup correctly.

Copy link
Member

@ViktorHofer ViktorHofer Apr 2, 2020

Choose a reason for hiding this comment

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

Not following. You can do two steps before the test build so the sequence would be:

  1. runtime.proj
  2. pretest.proj and
  3. tests.proj

Noteworthy, if you would wait until Monday, we could just invoke the lib-pretest lib-tests subsets which would handle all that for you. I plan to merge this on Monday (if ready) which introduces the libraries subsets #33553.

Copy link
Member Author

Choose a reason for hiding this comment

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

I ideally want to merge this tomorrow, since this PR touches a bunch of infra pieces. I can commit to reworking this once your PR is merged.

Copy link
Member

@ViktorHofer ViktorHofer Apr 2, 2020

Choose a reason for hiding this comment

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

No problem at all, I can make the changes afterwards.

@mangod9 mangod9 merged commit b927233 into dotnet:master Apr 2, 2020
@mangod9
Copy link
Member Author

mangod9 commented Apr 2, 2020

This is now merged, I will open another PR for couple of outstanding comments. Thanks everyone for your review and help on this.

@ViktorHofer
Copy link
Member

@mangod9 how did you merge this? Squash or merge? cc @jkotas

@mangod9
Copy link
Member Author

mangod9 commented Apr 2, 2020

regular merge, should it have been Squash?

@jkotas
Copy link
Member

jkotas commented Apr 2, 2020

@mangod9
Copy link
Member Author

mangod9 commented Apr 2, 2020

oops sorry, should have checked on that.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 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.

Build System.Private.CoreLib in a separate job from the CoreCLR product build
8 participants