Runners

Runners #

What Are Runners in CI/CD?#

Runners are the underlying infrastructure that execute jobs in your automation setup. They can be physical machines, virtual machines or containers responsible for executing the steps defined in your Workflow or Pipeline configuration file. A runner can reside in the

Both GitHub and GitLab utilize Runners, which operate in a similar way, although there are some platform-specific differences.

Types of Runners#

Instance Runners

Self-hosted GitLab instances can provide their own “Remote Hosted Runners”, which are then be available to all Projects hosted on that instance.

Read more about Instance Runners.

Remote Hosted Runners
Available: ,
Remote Hosted Runners are provided and maintained by the remote service, making them available to all users and projects. While some sizes or specific amounts of runtime may be offered free of charge, most remote services charge for the use of these runners.

These runners are readily availabe and ideal for automation procedures that do not involve sensitive data.

Read more about remote hosted runners: ,

Self-Hosted Runners
Available: ,
Self-hosted runners are user-configured virtual or physical machines that are registered with the remote service. They can be dedicated to specific GitLab Projects or GitHub Repositories, or shared across GitHub Organizations or GitLab (Sub-)Groups. These runners are well-suited for custom software and hardware requirements or specific security needs.

Read more about self-hosted runners: ,

Configuring Runners#

The configuration process for self-hosted runners is well-documented for both GitLab and GitHub. You can find the relevant documentation here: GitLab and GitHub. The process is streamlined to facilitate easy setup.

Both remote services offer a wide range of configuration options, which should be reviewed when actively setting up a self-hosted runner.

Here are some important considerations to keep in mind:

  1. Set Up Runners with Controlled Execution Environments
    In GitHub, each job can specify a Docker container using the container key. You can also adapt some configurations for self-hosted runners regarding the usage of this key.

    For GitLab, you need to specify an Executor for a self-hosted runner. The easiest choice is the Docker Executor, which allows you to run jobs in an isolated Docker environment.

    Using isolated execution environments not only enhances the reproducibility of individual jobs, but also reduces the risk of interference between jobs from different projects or repositories.

Warning

This is particularly important when allowing to run:

  1. Secure Your Runner Adequately
    A self-hosted runner has access to the repositories and projects it operates for and will receive any custom variables or secrets defined on the remote service. If you configure a self-hosted runner to access sensitive data, be aware that anyone with access to the project or repository on the remote service could potentially use the automation script to instruct the runner to access, alter, or share that sensitive data.

  2. Provide Enough Resources
    Ensure that your self-hosted runners have adequate resources (CPU, memory, disk space) to handle the expected workload. Monitor the performance and adjust the resources as necessary to prevent bottlenecks or failures during job execution.

  3. Consider All Resources When contemplating a switch to an automated setup, such as the GitLab Pipeline or GitHub Workflow, consider the resources you might allocate for a self-hosted runner. A self-hosted runner does not have to be confined to a data center or hosted on AWS; your laptop or workstation can also effectively serve as a runner.

Communication with Remote Service#

Runners communicate with remote services via HTTP/HTTPS and may require access tokens to fetch protected ressources. Both GitHub and GitLab provide tokens (e.g., the CI_JOB_TOKEN or the github.token) in the form of predefined variables that are available to the runner.

With these tokens, the runner can perform edits in a Project or Repository, whether in the actual repository or in assoicated features of the remote service, such as Issues or Merge/Pull Requests.

An important aspect of the runner’s communication with remote services is the mode with which communication is established. For both GitLab and GitHub, the runner instance that initiates communication with the remote service by polling. This has signifant implications for the network accessibility of a runner: while it requires outgoing connections, the runner does not need to be reachable from the internet, allowing it to reside in a semi-isolated environment.