You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 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:
runtime/eng/liveBuilds.targets
Lines 30 to 37 in a773bc3