Am Freitag, den 05.06.2020, 07:33 -0400 schrieb Dan Eble: > On May 24, 2020, at 06:51, Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > I'm currently researching how GitLab schedules jobs. Unfortunately it > > seems to be first-come-first-serve, so no priority for currently online > > specific runners. But every runner, if intermittent or not, has a > > chance of getting a job assigned. > > This has been disappointing. I've seen a slower runner taking a job while a > faster one sits idle. We could try increasing the check_interval option[1] > on the slower runners so that the faster ones are more likely to get jobs.
I agree that the system is missing a way to prioritize runners over others. This has been requested since a long time, so I wouldn't bet that such possibility is added soon. If my traffic analysis is right, check_interval is a bit of a lie: It sets the interval that the runner checks for new builds, but for gitlab.com every request takes up to 1 min. I would guess that they are implementing some form of queuing. Unfortunately, this means the probability to get a build is not proportional to check_interval. Additionally, the shared runners have a check_interval of 1s which means they're basically always polling for jobs. We definitely want our runners to get jobs whenever possible, so a high check_interval is counter-productive as well. The only "solution" I can think of is using tags on jobs and, for example, only schedule doc builds on capable runners. However, this doesn't work well with the shared runners where we can't add tags on our own 😞 Jonas
signature.asc
Description: This is a digitally signed message part
