Runner's accepted update-interval

GitLab CI/CD
,
1

Hi!

Does anyone know where the update-interval initial value of ‘1m0s’ comes from? I would like to lower its value, I have a relatively large Kubernetes cluster for CI/CD, and I have a bunch microservices with a pipeline of dozens of stages, usually 20-30 seconds run each, so, with this ‘1m0s’ initial wait per stage is a lot of idle time… :confused:

It’s not the ‘check_interval’, it’s something like “initial” ‘check_interval’, the runner doesn’t send anything to the Gitlab for 1 minute and after sends content in every 3 seconds (as default of check_interval):

Appending trace to coordinator...ok [...] Accepted update-interval=1m0s
Appending trace to coordinator...ok [...] Accepted update-interval=3s
Appending trace to coordinator...ok [...] Accepted update-interval=3s
Appending trace to coordinator...ok [...] Accepted update-interval=3s

It is v16.0.1-ee free, with a Kubernetes runner, mostly default values.

2

Hi Gábor,

I was just searching for the same thing.

After checking out and looking at the source code, I found out, that this value is currently hard-coded in gitlab itself:

Apparently gitlab had severe issues with polling job data during pipelines, that’s why they implemented a 60 second initial update interval, which then changes to 3 seconds, when the job (logs) are actually being watched.

Here is the link to the documentation: Troubleshooting CI/CD | GitLab

I hope it helps.

1 Like