3.3. Runner Configuration

So, if you want to provide dedicated resources to your project, you should configure a specific runner in a dedicated machine. Runners in GitLab are configured using the GitLab Runner application, installed on a separate machine or container. The configuration includes:

• Runner Registration:

Each runner must be registered with GitLab using a unique token obtained from the GitLab instance. Registration establishes a secure connection between the runner and the GitLab server., enabling it to receive and execute jobs.

• Executor:

The executor defines the environment in which jobs are executed. GitLab supports several executors, including Docker, Kubernetes, Shell, VirtualBox, and custom executors. The choice of executor depends on the project’s requirements, such as dependency management, isolation, and scalability. For instance:

  - **Docker Executor:** Runs jobs in isolated Docker containers, providing a consistent and reproducible environment for builds and tests. This is particularly useful for projects with dependencies or multiple build configurations.
  - **Shell Executor:**  Executes jobs directly on the runner's host machine, suitable for simple projects with minimal dependencies. This might be less ideal for our calculator project if we need to maintain a specific environment setup.

• Tags:

Runners can be tagged with keywords that associate them with specific jobs in the .gitlab-ci.yml file. Tags help route jobs to appropriate runners based on capabilities or requirements (e.g., python, calculator). For the calculator project, we might tag a runner with python to ensure the jobs are routed to a runner that has the right environment.

• Concurrency:

Concurrency settings control how many jobs can run concurrently on a single runner. This setting ensures optimal resource utilization and prevents job contention.