-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add workloads build #47225
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
Add workloads build #47225
Changes from all commits
18a13da
70ac2dc
9805125
0c15ed1
44e4bb0
199cc2c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,16 +4,26 @@ | |
they depend on assets from other verticals that are built in the first build pass. --> | ||
<ItemGroup Condition="'$(DotNetBuildPass)' == '2' and | ||
'$(OS)' == 'Windows_NT' and | ||
'$(TargetArchitecture)' == 'x64'"> | ||
'$(TargetArchitecture)' == 'x64' and | ||
'$(BuildWorkloads)' != 'true'"> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might make things cleaner to actually build these components via an opt-in property in the future instead of by default based on the BuildPass + config There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I agree. We can clean this up later. |
||
<ProjectToBuild Include="$(RepoRoot)src\Layout\VS.Redist.Common.Net.Core.SDK.MSBuildExtensions\VS.Redist.Common.Net.Core.SDK.MSBuildExtensions.proj" DotNetBuildPass="2" /> | ||
<ProjectToBuild Include="$(RepoRoot)src\Layout\VS.Redist.Common.Net.Core.SDK.VSTemplateLocator\VS.Redist.Common.Net.Core.SDK.VSTemplateLocator.proj" DotNetBuildPass="2" /> | ||
</ItemGroup> | ||
|
||
<!-- For product build, build the sdk bundle in the second build pass on windows as | ||
<!-- For product build, build the Workloads in the second build pass on windows as | ||
it depends on assets from other verticals that are built in the first build pass. --> | ||
<ItemGroup Condition="'$(DotNetBuildPass)' == '2' and | ||
'$(OS)' == 'Windows_NT' and | ||
'$(TargetArchitecture)' == 'x64' and | ||
'$(BuildWorkloads)' == 'true'"> | ||
<ProjectToBuild Include="$(RepoRoot)src\Workloads\VSInsertion\workloads.csproj" DotNetBuildPass="2" /> | ||
</ItemGroup> | ||
|
||
<!-- For product build, build the sdk bundle in the third build pass on windows as | ||
it depends on assets from other verticals that are built in the second build pass. --> | ||
<ItemGroup Condition="'$(DotNetBuildPass)' == '3' and | ||
'$(OS)' == 'Windows_NT'"> | ||
<ProjectToBuild Include="$(RepoRoot)src\Layout\redist\redist.csproj" DotNetBuildPass="2" /> | ||
<ProjectToBuild Include="$(RepoRoot)src\Layout\redist\redist.csproj" DotNetBuildPass="3" /> | ||
</ItemGroup> | ||
|
||
</Project> |
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.
Do you have numbers on how much longer the build is now due to the addition of the workloads?
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.
building the workloads themselves takes ~20mins, but signing is taking quite a lot more time. I believe we can optimize this since I see it signing all of the emsdk files again even though they are already signed.
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.
Because it's unpacking the content from the MSIs? Is it actually signing the files or just unpacking and then checking to see they are signed and then skipping them?
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.
I see them in the SigningRound* logs so I assume they're getting sent to ESRP. I haven't investigated yet why
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.
And the source nupkgs we're using from runtime/EMSDK, those should already be signed as part of the runtime build, correct? Is it possible we're pulling down the unsigned packages?
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.
The emsdk ones are always signed as part of its official build yes. For runtime they are signed either in it's current official build (when targetting a release branch) or in the VMR as part of one of the vertical builds.
So at least for emsdk it shouldn't sign the files again, ever.
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.
Signtool is supposed to be quite good now at avoiding re-signing. But I would expect re-signing in a build off main, since the source emsdk bits are unsigned.
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.
I changed that already since I expected this to be a problem but it didn't help. Need to dig deeper.