[ArPow] Onboard msbuild to arcade-powered source-build #2068
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
MichaelSimons
added
area-infra
Forgind
pushed a commit
to dotnet/msbuild
that referenced
this issue
Jun 1, 2021
This PR does the following: Adds the local build infrastructure that lets ArPow (arcade-powered source-build) run in this repo. See https://github.com/dotnet/source-build/blob/master/Documentation/planning/arcade-powered-source-build/onboarding/local-onboarding.md for more details about how it works. To try it out locally, run this on Linux: ./build.sh -c Release --restore --build --pack /p:ArcadeBuildFromSource=true -bl Implements source-build CI. To make sure ArPow (arcade-powered source-build) keeps working in this repo, we need to add it to PR validation. We also need it to run in the official build to publish source-built artifacts that can be tested downstream. See https://github.com/dotnet/source-build/blob/master/Documentation/planning/arcade-powered-source-build/onboarding/ci-onboarding.md for ArPow CI onboarding info. Incorporates the existing source-build patches into the repo. Some background on source-build patches, for anyone who isn't familiar with previous pushes for patch incorporation: A patch is essentially just a commit that has been extracted from Git into a .patch file that can be applied on demand. The effort to build .NET from source involves creating patches because repos make changes that are incompatible with source-build and need to be fixed up after the original released source code has already been finalized. When the original repo gets PRs over time for servicing, the PR changes sometimes conflict with the source-build patches, just like a merge conflict. The patch files need to be fixed up when this happens, which is a significant maintenance problem for the source-build team. Several times, the source-build team has pushed for "patch incorporation". This means to merge the commit represented in the .patch file into the original repo's official branch. Doing so prevents patch merge conflicts, because there's no longer a patch to merge against. However, patches inevitably pile up again when getting subsequent servicing releases to work in source-build. ArPow lets us end this maintenance-heavy process. By running source-build inside CI, patch merge conflicts will immediately block PR validation, so fixup can be handled in place, not solely by the source-build team. Running source-build in CI also means creating new patches won't be necessary except in exceptional circumstances. See https://github.com/dotnet/source-build/blob/master/Documentation/planning/arcade-powered-source-build/implementation-plan.md for more details on the ArPow implementation plan. Fixes: dotnet/source-build#2068.
|
While verifying that the build published the intermediate NuGet package to DARC correctly, I realized the package is RID specific because |
Forgind
pushed a commit
to dotnet/msbuild
that referenced
this issue
Jun 2, 2021
Fixes dotnet/source-build#2068 Context This was something I discovered while trying to consume the Source-Build intermediate package produced by the first ArPow changes made in #6387 Changes Made Set the SourceBuildManagedOnly property correctly. How Tested Verified the resulting Microsoft.SourceBuild.Intermediate.msbuild package is not named rid specific.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: