Re: helping with testing resources

[Jonas Hahnfeld]

Am Freitag, den 05.06.2020, 07:33 -0400 schrieb Dan Eble:
> On May 24, 2020, at 06:51, Jonas Hahnfeld <hahnjo@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