Only build BuildAfterTargeting pack on win-x64 by wtgodbe · Pull Request #60658 · dotnet/aspnetcore (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation7 Commits4 Checks27 Files changed
Conversation
This file contains hidden or 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
[ Show hidden characters]({{ revealButtonHref }})
Fixes #60530. This project just produces some .nupkg's, and doesn't build anything for the sharedFx/Ref pack. We can be certain that it never will, because by definition it builds after the targeting pack.
BuildAfterTargetingPack.csproj introduces flakiness into the build because it sometimes causes a race condition that leads to file conflicts - therefore we should build it as infrequently as possible (only on win-x64).
Test build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2652111&view=results
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.
Only build BuildAfterTargeting pack on win-x64 in VMR Only build BuildAfterTargeting pack on win-x64
There was a publishing failure in the VMR build - I don't think it's related, but not sure. Waiting to hear back from some VMR folks
Edit: The failure is unrelated
What packages does this produce? In the VMR, we prefer every vertical to produce rid agnostic packages as upstream consumers might depend on it.
What packages does this produce? In the VMR, we prefer every vertical to produce rid agnostic packages as upstream consumers might depend on it.
Microsoft.AspNetCore.Grpc.JsonTranscoding & Microsoft.AspNetCore.Grpc.Swagger are the two shipping packages produced by this project (they have to build after the targeting pack because they use Swashbuckle.AspNetCore, which has a FrameworkReference to Microsoft.Aspnetcore.App in order to resolve Microsoft.Aspnetcore.Routing)
Did you double check that none of these packages are used in upstream repos like sdk? This change feels like a workaround to a build infrastructure issue to me but if diagnosing the actual issue isn't feasible or wouldn't help short-term, I'm fine with it as-is.
Did you double check that none of these packages are used in upstream repos like sdk? This change feels like a workaround to a build infrastructure issue to me but if diagnosing the actual issue isn't feasible or wouldn't help short-term, I'm fine with it as-is.
Yeah, the gRPC packages are not referenced by SDK. I agree this is a hack, but I'm bothered enough by the build reliability hit that I think it warrants doing something in the short term. Long-term I want to get rid of all of our custom reference resolution stuff, which should improve issues like this one
Labels
Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
2 participants
