Open bradfitz opened 7 years ago
And gomote access is in there somewhere too.
CL https://golang.org/cl/38306 mentions this issue.
CL https://golang.org/cl/40397 mentions this issue.
Change https://golang.org/cl/70430 mentions this issue: cmd/coordinator: attempt to run newer work before older work on buildlets
Change https://golang.org/cl/132076 mentions this issue: cmd/coordinator: start of a scheduler, not yet enabled
Change https://golang.org/cl/205078 mentions this issue: cmd/coordinator: finish the scheduler code, at least mostly
Change https://golang.org/cl/207079 mentions this issue: cmd/coordinator: add tests for the scheduler, and resulting fixes
Change https://golang.org/cl/207178 mentions this issue: cmd/coordinator: delete reverse buildlet pool's high priority mechanism
Change https://golang.org/cl/207179 mentions this issue: cmd/coordinator: clean up HTML status, add scheduler status
Change https://golang.org/cl/207180 mentions this issue: cmd/coordinator: enable the scheduler
Change https://golang.org/cl/207418 mentions this issue: cmd/coordinator: omit scheduler progress times when missing or irrelevant
Change https://golang.org/cl/207464 mentions this issue: cmd/coordinator: favor trybot work over post-submit work on process start
Change https://golang.org/cl/208277 mentions this issue: cmd/coordinator: plumb commit time and branch from findWork down into scheduler
Currently if there are N builds waiting on a buildlet type (due to lack of machines or quota), the current implementation is a bunch of goroutines fighting over a mutex.
It's random who wins and gets the buildlet.
We should have them register interest and when a buildlet becomes available, pick the highest priority one.
Example priorities in order:
etc.
/cc @danp @kevinburke