Try out BuildProjectReferences=false in Components#37017
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
GitHub and AzDO are very confused: GitHub tried to cancel previous build for this PR but a few jobs are still running 🤞 AzDO and GitHub eventually catch up (and that this change works 😃) |
That's what I get for doing manual builds before opening a PR :D |
dougbu
left a comment
There was a problem hiding this comment.
WFM though I'm surprised this doesn't cause new and different ordering issues e.g. Wasm.Prerendered.Server.csproj dependencies not being ready when Microsoft.AspNetCore.Components.E2ETests.csproj asks Wasm.Prerendered.Server.csproj to build.
Recommend draft PRs unless you need to test things w/ internal builds. |
Yes, I wondered too. Does this change mean we're just hoping the build ordering/parallelism happens to work out OK, or is there anything that ensures it? I'd be concerned if we're merging this on the basis that it happens to pass in CI by chance.
|
pranavkm
left a comment
There was a problem hiding this comment.
Isn't this problematic? If there's a reference that is unique to one of these projects, it'll never get built?
|
@pranavkm that part I get 😄 The item group @BrennanConroy is changing is only used on the CI or when building the |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
Running again for sanity, planning on merging if it passes again. |
Asking again, with this change, is there anything that causes the build ordering/parallelism to be valid, or does it just happen to work by chance? |
Components being near the end of the stack is probably why this just works. I understand your ordering concerns but I'd rather try this out to see if the 'file in use' issues stop happening and revert/file an issue if we see ordering issues. Right now we have little to no information about the build problems we've been seeing and this PR will hopefully give us some info. Plus, Components already has this change for another of the project references so build ordering isn't a new problem here, it just might be more likely now. |
The changed project also has a lot of dependencies, likely covering (almost❔) everything the few dependencies passed |
|
OK, sounds reasonable! We'll have to see how this turns out in practice. |
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/aspnetcore/actions/runs/1292816098 |
Same change as #34137 which was made to try and reduce build flakiness.
https://github.com/dotnet/aspnetcore-internal/issues/3915#issuecomment-928011626 for more info