8000 Remove repo inner build · Issue #4249 · dotnet/source-build · GitHub
[go: up one dir, main page]

Skip to content

Remove repo inner build #4249

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

Closed
ViktorHofer opened this issue Mar 25, 2024 · 2 comments · Fixed by dotnet/dotnet#176
Closed

Remove repo inner build #4249

ViktorHofer opened this issue Mar 25, 2024 · 2 comments · Fixed by dotnet/dotnet#176
Assignees
Labels
area-build Improvements in source-build's own build process

Comments

@ViktorHofer
Copy link
Member
ViktorHofer commented Mar 25, 2024

We discussed this in a previous source-build sync meeting. Given that repo publishing doesn't run in the repo outer build anymore when constructing the product, it might be interesting to explore if the outer <--> inner repo build distinction could be eliminated. This would provide at least the following benefits:

  1. Improved UX: Having one less build layer means it's easier to debug failures and reason about the layer in which an error occurred. It also means one less binlog and log per inner build invocation (i.e. aspnetcore does more than one inner build).
  2. Performance: Avoiding the additional build phase per repo build contributes to build performance. Think about msbuild start-up cost, evaluation cost, Arcade build scripts, package downloads, etc.
  3. Separation of concerns: Today, DotNetBuild.props / SourceBuild.props in repositories condition properties, items or targets on if the current build is a VMR build (DotNetBuildOrchestrator=true). By triggering the current repo inner build directly from the VMR, those setting could be moved into the VMR orchestrator. This would also make it easier to put all binlogs into the product artifacts/log directory.

Cons:

  1. Infrastructure for building a repository from source outside of the product would presumably still require source-build specific settings to be listed in SourceBuild.props / DotNetBuild.props pre repository. This could result in duplication of inputs.

Removing repo inner builds would entail at least the following work items:

  1. Sequence the existing source-build infrastructure like prebuilt detection as a post-build step into the current repo inner build (similar to what was done for the Publishing epic).
  2. Move logic from the repos' DotNetBuild.props / SourceBuild.props into the VMR repo-projects. Make sure that all the inputs expected, are passed in. Pay special attention to the inner build args: https://github.com/dotnet/arcade/blob/c936d1bc358744730613d8ce54bc3e0294e5ea56/src/Microsoft.DotNet.Arcade.Sdk/tools/SourceBuild/SourceBuildArcadeBuild.targets#L65-L85
  3. Make sure that building a repository from source outside of the product build still works.
@ViktorHofer
Copy link
Member Author
ViktorHofer commented Nov 18, 2024

It would be interesting to explore if we could keep the current DotNetBuild.props as the place that controls how the repo gets built as part of the product (either inside the VMR or as a standalone repo build). I wonder if the VMR's projects, i.e. runtime.proj could import that file directly and then use the calculated CLI args / properties by reading from the InnerBuildArgs property and appending that to the repo build command.

@ViktorHofer
Copy link
Member Author

I'm taking a stab at this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-build Improvements in source-build's own build process
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants
0