build: fix/speed-up build graph dependencies #924
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When building the entire solution, we need to ensure the various "Installer.<OS>" and "Packaging.<OS>" projects are not built at the same time as other projects, especially on Windows, where we may hit file locking problems. The installer projects call a build script internally that calls a `dotnet publish` on various projects. By making the installer projects reference (but not consume) the dependent projects we ensure MSBuild won't build them until the end, and prevent file access errors. At the same time, we can probably remove the "-m:1" flags that tell MSBuild to only build one project at a time.
derrickstolee
approved these changes
Oct 25, 2022
There was a problem hiding this comment.
I took a quick glance at our CI history to see how things improved. The end-to-end time seems to have a moderate speedup of 10-15 seconds (based on very limited samples) but individual jobs do get a lot faster. Windows seems to speed up by a minute. The macOS build seems to be the limiter in the build I saw.
Still, the logic here is sound. Thanks!
Merged
ldennington
added a commit
that referenced
this pull request
Nov 3, 2022
Changes: - Check for broken links in documentation (#700) - Support macOS `arm64` installs via Homebrew (#798) - Validate installers before publishing (#813) - Auto-generate maintainer away notification issues (#842) - Install dotnet via Jammy feeds on Ubuntu 22.04 and greater (#839) - Access Azure storage account using service principle credentials (#851) - Update documentation to use reference-style links (#680) - Unify documentation line length (#862) - Add generic username/password UI (#871) - Bitbucket DC OAuth support (#607) - Distribute GCM as a dotnet tool (#886) - Drop `-core` suffix from entry executable #551 - Speed up build graph (#924)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
1 similar comment
This comment has been minimized.
This comment has been minimized.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When building the entire solution, we need to ensure the various "Installer." and "Packaging." projects are not built at the same time as other projects, especially on Windows, where we may hit file locking problems.
The installer projects call a build script internally that calls a
dotnet publishon various projects. By making the installer projects reference (but not consume) the dependent projects we ensure MSBuild won't build them until the end, and prevent file access errors.At the same time, we can probably remove the "-m:1" flags that tell MSBuild to only build one project at a time.