Runners
Runners
Runners are used to execute jobs in GitLab CI
Executors interface with infrastructure
XXX
Runners
Shell
Jobs are executed in the context of the runner
Upsides
No infrastructure requirements
Downsides
Jobs use the same execution environment
Pollution by job commands
Using containers
Dedicated execution environment per job
Executor talks to infrastructure:
- Creates volume for working directory
- Run helper container for checkout into volume
- Run build container for build using volume
Services are executed in separate containers next to the build container
Docker
Jobs are executed in a dedicated container
Kubernetes
Jobs are executed in a dedicated container in a pod
Runner scopes
Instance runners
Shared across all groups and projects
Reserved for instance administrators
Managed from admin area
Group/project runners
Shared across a group or a project
Accessible to members with Owner role
Shared runners can be disabled
Runner tags
Runners can have tags
Tags specify features based on…
- Operating system, e.g. linux, windows
- Networking locations, e.g. datacenter, aws, azure
- Hardware, e.g. compute, gpu
- Executor, e.g. shell, docker, kubernetes
Selecting runners in pipelines
Each job can use a different runner:
job_name:
tags:
- foo
All features work across different runners
Pro tip 1: Finding existing runners
No single place to discover runners
See the CI/CD settings in the runner section
Applies to groups and projects
The list shows runners available
Offers the option to disable instance runners
Pro tip 2: Special purpose executors
Instance executors for auto-scaling (builtin)
Idle VMs are possible to speed up job execution
Support for AWS, Azure and GCP