GitLab Runners
After considering using CircleCI or Jenkins to do some build automation and get some software under test, I asked myself “What if GitLab could do everything I need without integrating other tools?”
To try out GitLab’s testing setup I built Create-React-App and committed it to a new repo on my personal account. I was able to run a build and test with minimal configuration on a shared runner. It seemed too good to be true! What exactly is a runner I asked myself. I assumed it was a shared Docker Linux test environment to build and test on.
I cloned the same B-R-A repo to my work-hosted gitLab and could not get it to build or anything using the shared runners on offer. Then I scaled back to the simplest possible scenario – a single GitLab build file (.gitlab_ci.yml) that creates a file and then tests if the file is there.
I got the same results using this approach: works on my personal, fails on work-hosted. Hmmm. Must be something about the runner, since that was the only difference between GitLabs. I don’t know anything about runners – I guess I had better learn…
So really, what is a runner? Conceptually, it is an environment where a project can be built, run and tested. It allows one to create their own infrastructure for running GitLab jobs.
But “runner” is an overloaded concept that we can break down into pieces for a more precise definition:
| Runner Access: | Shared: A runner can be published as a shared resource that listens for jobs in a pipeline to run. |
| Specific: A runner configured for a particular project and not shared among any other projects. | |
| Runner Configuration: | If a shared runner is not available to provide a required environment, a specific runner can be configured in Gitlab-> Settings-> Runners->Specific runners. |
| Runner Service: | In at least some cases a service needs to be installed that carries out the instructions defined in the .gitlab-ci.yml. An example is when running tests on a local machine. The service listens for a job signal emitted from a GitLab host instance and carries out the instructions. |
| Runner Executor: | Runners can be defined as a Docker and VirtualBox instance. But in this case container can mean a Windows/MacOS/Linux machine, a Shell or a Virtual machine. |
| Runner Location: | A runner can be hosted on a cloud service like AWS, a local development workstation or on the Gitlab host. |