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

Local live-live builds #494

Merged
merged 83 commits into from
Dec 13, 2019
Merged

Conversation

jkoritzinsky
Copy link
Member

@jkoritzinsky jkoritzinsky commented Dec 3, 2019

This PR implements local live-live builds. The eng/liveBuilds.targets MSBuild file is the central location for live dependency file discovery. There are various MSBuild property hooks in there to enable overriding the location of the various consumed live components.

Work completed in this PR:

  • Libraries consumes:
    • A live copy of the CoreCLR build's shared framework and System.Private.CoreLib output.
  • Installer consumes:
    • A live copy of the CoreCLR build's shared framework and System.Private.CoreLib output
    • A live copy of the Libraries shared framework ref and implementation assemblies.
    • A live copy of Microsoft.NETCore.Platforms and Microsoft.NETCore.Targets
  • CoreCLR managed test build consumes:
    • A live copy of the Libraries shared framework and OOB ref assemblies.
  • CoreCLR Core_Root generation:
    • A live copy of the Libraries shared framework and OOB implementation assemblies.
  • Customization points for each "unit" of output that is consumed between subset categories.
  • Subsets that have dependencies are serialized such that a root build will build subsets in the correct order for inter-subset dependencies.

Future work for another PR once we are off the critical path:

  • Refactor out target overrides in src/installer/pkg/projects/netcoreapp/src/localnetcoreapp.override.targets so we can send back a patch to Arcade and remove localnetcoreapp.override.targets.
  • Extend eng/liveBuilds.targets to have a target for consuming a live build of the hosting layer.
  • Consume a live build of the hosting layer in the CoreFX test build instead of consuming packages.

Superscedes #55 (needed to be recreated after the repo went public).

…dependencies are in the building subset/subset category.
…ding a new BinplaceConfiguration. Update test_dependencies in the CoreCLR tree to use that to restore OOB libraries.
…he reference is only needed at runtime and Core_Root already has System.Drawing.Common).
…live world, we'll run this test configuration by pointing the CoreFX test host build step at the artifacts from a checked CoreCLR build (possible in both local and CI builds).
…(breaks the live-live build on a clean system).
…ms to be unneeded since the SDK now packages a RID graph. Use the live RID graph in test_runtime.csproj where we may actually be looking for the live RID graph.
@jkoritzinsky
Copy link
Member Author

I am so confused by the failures here. The failures say that the CoreCLR subset was not found at path/to/artifacts/transport/coreclr, but just 3 steps earlier, the CoreCLR artifacts were downloaded and extracted to that exact folder...

@jkoritzinsky
Copy link
Member Author

And with the exact same parameters it passes locally....

@jkoritzinsky
Copy link
Member Author

And the exact same thing works perfectly in the libraries builds.

jkoritzinsky and others added 4 commits December 11, 2019 17:05
…the LibrariesConfiguration is different from the installer build configuration.
… be consistent with the libraries build so our package versions match.
…typo in TargetPath for CoreCLR assets (runtime instead of runtimes).

Fix paths for CoreCLR cross-target files as well as crossgen to place them in the correct directories.
@jkoritzinsky
Copy link
Member Author

Everything is passing except the check for the "platform manifest" in the Microsoft.NETCore.App.Ref targeting pack. This is related to https://github.com/dotnet/core-setup/issues/8853.

@ViktorHofer
Copy link
Member

That's great! Does Davis's note help?

I think I should work on this, and in the meantime I think it's reasonable to disable "full" platform manifest generation (set BuildFullPlatformManifest to false) to unblock dotnet/runtime "live live" builds.

@jkoritzinsky
Copy link
Member Author

I already followed that when I started this PR and I think that might be part of what's causing the issue now.

@ViktorHofer
Copy link
Member

ViktorHofer commented Dec 13, 2019

@jkoritzinsky is the PR ready to be merged?

@jkoritzinsky
Copy link
Member Author

Yep!

@ViktorHofer
Copy link
Member

Niceeee. I assume you will merge it after sending out the mail? :)

@jkoritzinsky
Copy link
Member Author

Will do!

@jkoritzinsky jkoritzinsky merged commit 2458930 into dotnet:master Dec 13, 2019
@jkoritzinsky jkoritzinsky deleted the live-live-builds branch December 13, 2019 18:31
@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.

6 participants