Update "Build VS Bootstrapper" #9376
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
To perform partial NGEN of our installed assemblies--where NGEN only pre-JITs the methods we need for a scenario, rather than every method--we need optimization data produced by OptProf runs. We run our own little test that produces this optimization data on every scheduled build of our `main` branch. This test is pretty straightforward--it loads a solution with a a handful of projects in VS. We run the test out of our `main` branch so that it can incorporate our latest changes without the need for us to insert into VS. However, this means the test needs to install and run a build of VS that actually has those changes. We accomplish this with the `MicroBuildBuildVSBootstrapper` task. We give it a build channel and it uses the latest build from that channel as a baseline. We also point it at our locally-produced .vsman file describing our setup components, and it merges the two to produce a new VS installer (e.g. vs_enterprise.exe) that combines the two. The channel we specify in this "Build VS Bootstrapper" task is "int.main" which tracks builds out of the VS "main" branch. This is generally what we want as most of our builds and insertions are from the dotnet/project-system "main" branch into the VS "main" branch. However, it is completely wrong when it comes to release/servicing branches. In the case of our "dev17.8.x" branch, for example, we're producing binaries that target the 17.8 release of VS but end up incorporating them into an installer based on VS "main", which is currently a 17.10 branch. This results in our package not loading properly, which in turn means the test fails and any optimization data we produce does not cover our assemblies. Without that data we get full NGEN of our assemblies at install-time. Since the "dev17.8.x" branch is a 17.8 servicing branch, this commit updates us to target the "int.rel/d17.8" channel instead. This means the installer will be based on builds out of the VS "rel/d17.8" branch, which is what we want.
tmeschter
commented
Jan 12, 2024
| @@ -133,7 +133,7 @@ jobs: | |||
| inputs: | |||
| bootstrapperCoreVersion: latest | |||
| vsMajorVersion: $(SetVisualStudioMinimumVersionVariable.VisualStudioMinimumVersion) | |||
| channelName: int.main | |||
| channelName: int.rel/d17.8 | |||
There was a problem hiding this comment.
I'm somewhat guessing at the channel name here; I couldn't find many examples.
Based on examples I've found elsewhere I think we need "int.d17.8" as the channel name rather than "int.rel/d17.8".
haileymck
approved these changes
Jan 12, 2024
|
@tmeschter should we include this as a step on our branch check list? |
|
@drewnoakes Yeah, I had the same thought. I'm going to update that once I actually get this working again. |
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.
Related to AB#1939807.
To perform partial NGEN of our installed assemblies--where NGEN only pre-JITs the methods we need for a scenario, rather than every method--we need optimization data produced by OptProf runs. We run our own little test that produces this optimization data on every scheduled build of our
mainbranch. This test is pretty straightforward--it loads a solution with a handful of projects in VS. We run the test out of ourmainbranch so that it can incorporate our latest changes without the need for us to insert into VS. However, this means the test needs to install and run a build of VS that actually has those changes. We accomplish this with theMicroBuildBuildVSBootstrappertask. We give it a build channel and it uses the latest build from that channel as a baseline. We also point it at our locally-produced .vsman file describing our setup components, and it merges the two to produce a new VS installer (e.g. vs_enterprise.exe) that combines the two.The channel we specify in this "Build VS Bootstrapper" task is "int.main" which tracks builds out of the VS "main" branch. This is generally what we want as most of our builds and insertions are from the dotnet/project-system "main" branch into the VS "main" branch. However, it is completely wrong when it comes to release/servicing branches. In the case of our "dev17.8.x" branch, for example, we're producing binaries that target the 17.8 release of VS but end up incorporating them into an installer based on VS "main", which is currently a 17.10 branch. This results in our package not loading properly, which in turn means the test fails and any optimization data we produce does not cover our assemblies. Without that data we get full NGEN of our assemblies at install-time.
Since the "dev17.8.x" branch is a 17.8 servicing branch, this commit updates us to target the "int.rel/d17.8" channel instead. This means the installer will be based on builds out of the VS "rel/d17.8" branch, which is what we want.
Microsoft Reviewers: Open in CodeFlow