Closed
Description
The PR to re-enable full platform manifest harvesting in dotnet/runtime (#1594) has some known bad bits. It didn't seem worth it to me to fix them in the harvesting implementation, because I believe we need to replace the harvesting approach altogether for source-build.
The list:
- It downloads a decent amount more data during the build. This hasn't added more than 3 or so minutes in my testing builds, but could be a problem at some point.
- @safern suggested piecing together the platform manifest data during the CoreCLR and Libraries builds and transferring that rather than the entire set of artifacts, to reduce size: Generate full platform manifest in official build #1594 (comment)
- There's a redundant download: each Installer job downloads one of the platform's artifacts twice. Once to use to create the runtime being built on that machine, again specifically for platform manifest harvesting.
- The full manifest infra isn't tested in PR validation. The main runtime pipeline doesn't currently include all the platforms necessary to assemble a full platform manifest.
- It adds 21 build steps to each installer job. 1 to download all the artifacts, 20 to extract each artifact using the built-in unzip step while preserving folder names.
- It is difficult to run locally. You have to download every artifact manually, unzip/untargz them, and arrange them properly. (Let alone trying to run every local build yourself on a bunch of your own machines!)
- The RID => Platform mapping is hard to read. It seems like items would be significantly clearer: Generate full platform manifest in official build #1594 (comment)
runtime/eng/liveBuilds.targets
Lines 30 to 37 in a773bc3