Allow configuring GitLab runner priority
Status update (2023-08-03)
- We have not determined a path forward to address the pain points described in this issue.
- After a few customer interviews starting the week of 2023-07-24, I have created an issue aimed at developing a proof-of-concept solution.
Problem to solve
I have multiple runners for a project which run on very different machines, some slow (my dev machine), some fast (build server). I'd like to prioritize the runners, so that gitlab always tries to use the runners in a certain order, in my case: use the fasted idle/available runner possible. So I would always the the shortest build times.
Proposal
It would be great to see the ability to define runner priority orders in the gitlab runner interface.
For instance, you could have multiple runners with the tag ios, but if a certain runner is available you want it to run on that one first. This could be because that runner has better hardware and the others are there as spares, but the first one can run the build faster.
Possible MVC implementations:
- Allow multiple runner tags to indicate priority of the runners to be used. eg; if tag 1 is unavailable default to tag 2, tag 3, etc.
Possible Future UI implementations:
- a switch on the runners page to select between (old)round robin and (new) prioritized
- drag and drop the runners into a certain order, when in prioritized mode
Implementation notes
- Such a change will require changes in rails
- This proposal will increase the - already huge - complexity of the SQL queries that are powering jobs scheduling. We may have to get back to the idea of a
CI Daemon
that would handle scheduling and therefore not relying on the DB.
Edited by Darren Eastman