-
Notifications
You must be signed in to change notification settings - Fork 125
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
The NetCore-Public-XL pool can't handle the volume of PRs in sdk #4365
Comments
Before doing 2, let's confirm what the size/cost of this pool is first to make sure the increase in volume won't be a problem overall. 1 is good though, I think. |
Capturing a side conversation we had on this. The dependency flows we would batch are the ones that are stable and rarely cause any breaks. The contentious flows like runtime, aspnet, roslyn, etc. would remain standalone flows. Aside from these two, I believe we can justify the ROI here on increasing the pool size. |
Submitted dotnet/sdk#40627 for action item number one. |
We are hitting resources issues already but that might due to me re-spinning a bunch of builds that failed. Let's see how this looks tomorrow. |
@ViktorHofer - Can you provide an update on how frequently we are hitting pool resource availability issues? Is this something we need to take action on now? |
I didn't see any recent hangs or timeouts because of this. I think that dotnet/sdk#40627 significantly helped. Closing. |
We will soon switch the VMR to be produced out of sdk instead of installer. This means that PRs will trigger the sdk-source-build and sdk-unified-build pipelines. Sdk has between 15-20 PR builds on average which means that we trigger 7 * 18 builds in the NetCore-Public-XL pool in average just for the VMR PRs. Rolling builds also queue a significant number of builds.
To handle that volume and avoid timeouts we should consider the following before enabling the pipeline in sdk:
I think we need to do both before we can enable the pipelines in sdk.
cc @mmitche @premun @marcpopMSFT @MichaelSimons @MiYanni @ellahathaway
The text was updated successfully, but these errors were encountered: