Reconsider nextWorker for each build request #6277
Conversation
When the ability for nextWorker to make decisions based on the build request was added, the processing of workers was not updated to ensure it would consider each request separately. This caused the immediate issue that popNextBuild would only consider the first build request if nextWorker was unable to place it. Additionally, once a worker had been asked to consider a given build request, this decision persisted to future unrelated build requests if the build was prevented from starting by Builder.canStartBuild. The fix for both of these issues is always considering every available worker for each build request as they are chosen by nextBuild.
Codecov Report
@@ Coverage Diff @@
## master #6277 +/- ##
==========================================
+ Coverage 91.84% 91.92% +0.07%
==========================================
Files 345 334 -11
Lines 36888 37513 +625
==========================================
+ Hits 33881 34482 +601
- Misses 3007 3031 +24
Continue to review full report at Codecov.
|
|
This PR looks good in principle. We'll need to have some kind of performance test to ensure that we don't regress performance on busy Buildbot instances. |
|
Is there an example of doing a perf test somewhere or would this be a one-off thing? |
We currently don't have normal performance tests that could be easily ran. I was more expressing an opinion of what needs to be done, not necessarily by you. I think you can continue working on the other things and we can look into what options are for testing performance after you've finished. |
This is a proposed fix for #6251 which maintains the existing nextWorker API. I haven't yet added unit tests to catch the issue or updated docs, but will do so before removing the draft status from this PR if this approach looks good.
Contributor Checklist:
newsfragmentsdirectory (and read theREADME.txtin that directory)