-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Merge CoreCLR-based official builds legs into one leg per platform #92901
Conversation
…s/names to use the right variable names.
…fferently in the installer build-linux-package step, will fix this later).
…te job from the Windows CoreCLR builds.
…for Linux as we don't use it any more
…ll of the separate CoreCLR/Libraries/Installer jobs that existed to support these jobs as they were.
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsToday, we split our official builds for CoreCLR-based artifacts into multiple separate jobs and we flow artifacts between the jobs. This adds significant complexity to our build and takes longer due to waiting for machine provisioning. Additionally, for the VMR, we need to build each platform in a single job as we need to be able to build all of the constituent repos in one job. This PR merges each CoreCLR platform to build in a single job. It continues to keep one job for the CrossDac packages, as those need to be built cross-machine. Additionally, it preserves the Libraries AllConfigurations leg as a separate job as that is platform-agnostic. Various platform legs for CoreCLR have additional pre and post build steps to account for signing (DAC/DBI and macOS tools), entitlements (macOS), uploading artifacts for the CrossDac job (Linux), and building installers in specific containers (Linux).
|
DAC/DBI signing has been validated. |
…o the signing now entirely in the merged jobs (and never use this platform for official builds any more)
…ct build even in the runtime pipeline.
Official build link for |
… the same container.
Official build link for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, although I'm not sure I completely understand the crossdac interaction
@hoyosjs can you take another look at the CrossDac work and approve/request changes? I think I've got it all right, but I really want to make sure I don't break that space. |
Looks like this broke the official build by producing packages with -ci version |
Today, we split our official builds for CoreCLR-based artifacts into multiple separate jobs and we flow artifacts between the jobs. This adds significant complexity to our build and takes longer due to waiting for machine provisioning. Additionally, for the VMR, we need to build each platform in a single job as we need to be able to build all of the constituent repos in one job.
This PR merges each CoreCLR platform to build in a single job. It continues to keep one job for the CrossDac packages, as those need to be built cross-machine. Additionally, it preserves the Libraries AllConfigurations leg as a separate job as that is platform-agnostic.
Various platform legs for CoreCLR have additional pre and post build steps to account for signing (DAC/DBI and macOS tools), entitlements (macOS), uploading artifacts for the CrossDac job (Linux), and building installers in specific containers (Linux).
Note
Official build link: https://dev.azure.com/dnceng/internal/_build/results?buildId=2280331&view=results
Important
Due to branch restrictions on the service connection for the DAC/DBI signing, I was unable to validate it end-to-end.