Roll your own GitLab CI runners

GitLab offers free shared runners (with a quota) to run your CI pipelines. This is extremeley generous and I've come to depend heavily on using them for my projects. Combined with their free tier, I don't see a reason to not use GitLab. I haven't paid a single dime for one year, things are stable and there's only little down time on the shared runner pool.

But - for these rare occurrences, you can easily add a local runner to a pool, either on a group or project level. The easiest way to set this up on a Mac is to use Docker Desktop to run a GitLab runner container and register it on gitlab.com.

Also, check the following pages to understand how things work on GitLab's side: GitLab and Docker runners & registering runners with GitLab

Important note: if your build process runs a docker-in-docker build, you need to modify your .gitlab-ci.yml file to set an environment variable to empty, if you don't want to mess around with TLS certificates.

Content Plugin missing (blockSourceCode)

This took me a while to figure out. And if you're only planning to temporarily run a local runner, certificates probably won't matter much for the few hours you'll actually be using this workaround. If you plan to use local runners indefinately, please follow the reference implementation and use TLS certificates.

With that said, the rest is fairly simple.

Before you start

  • Install Docker Desktop on Mac if you don't have it already
  • Find your token needed to register a runner on GitLab

Setting up the container

This downloads the docker image and starts a container called 'gitlab-runner'. Note that the local gitlab-runner configuration will be stored in /Users/Shared/gitlab-runner/config - and not within the container itself.

Content Plugin missing (blockSourceCode)

Registering the runner

This line launches the runner registration within the previously started container and registers the runner with the token you got from gitlab.com. We also define the runner's configuration.

Content Plugin missing (blockSourceCode)

That's it - your local runner should show up on gitlab.com as soon as you register it and every new pipeline started on either a project or group level (depending to which you just registered the runner to) will prioritize the local runner over the shared-runner pool.

… my next thought was to have a few Raspberry Pi's locally to run my own pool. This should be a great little project and finally a reason to use those spare CPU cycles. However, this will only work as long as your entire build works on ARM as well as on 64bit x86. And it probably will be magnitudes slower than even a runner from the shared pool gitlab.com offers for free. So, I guess - while it would be fun to set this up, it's not really useful. :-P

Photo by British Library on Unsplash

Published: 10/29/2019

© 2020 genox.ch – emaillegal