[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: helping with testing resources

From: Jonas Hahnfeld
Subject: Re: helping with testing resources
Date: Sun, 07 Jun 2020 11:36:50 +0200
User-agent: Evolution 3.36.3

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


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]