GitLab runtimes

Many of the MinGW autotools CI build jobs that I’m currently working on takes more that the allowed 1 hour to build and thus fails with: ERROR: Job failed: execution took longer than 1h0m0s seconds.

I’ve measured the actual build time in a job that actually finishes before the deadline and the actual build time (excluding installation) is 45 minutes. The same process takes around 15 minutes on my local Windows 10 laptop with this CPU spec: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz 2.69 GHz.

Is it reasonable that the GitLab servers are that slow in comparison?

All the jobs can be found in this pipeline.

It’s possible. These are backed by GCP, right? My experience with other GCP-backed CI providers is that there is a massive difference in what tier the CI provider are using. Empirically for the same task:

  • Travis CI: regularly hitting a 50 minute timeout. I had to shard the task into 5 separate jobs, which each individually occasionally hit the 50 minute timeout too.
  • Cirrus CI: same unsharded task finishes in <25 minutes.
1 Like

Yeah I’m also not very surprised to hear that cloud VMs we get for free might be underpowered, particularly in how much CPU they can access.

1 Like

On internal GitLab server we were able to alter the default timeout, not sure if you can on the public version: Configuring runners | GitLab

There seems to be a hard limit of 3600 seconds on the Windows cloud runners:

I was going to suggest my favorite solution to accelerating any system: do less. We could avoid building Lefty on MinGW. Though looking at ci/build.sh it looks like we already don’t build Lefty.

Do you know how many cores these runners have? We could run make -j …. It will make the build output a bit unreadable, but I don’t think we’re in the phase of paying down MinGW compiler warnings yet, so maybe this is bearable.

No, and I’m not sure that’s how they work. We might be sharing their capacity with other jobs.

I’ve tried that now. It might have given a 5% improvement. The fastest of the problematic jobs that took very close to 60 minutes without -j, which sometimes succeeds and sometimes fail, now took 57 minutes, but I’ve done a rebase on main in between so it might not be significant. The other three jobs still failed though.

57-min job:

All jobs:

What I’m hearing is that you’d like to join me in the dead code removal quest :wink:

Your hearing is extraordinary :grin: