I highly recommend setting up your own Runner for your projects. The shared instance runners can become clogged up with other projects or experience issues like rate limits or running out of storage. If you depend on Pipelines or make extensive use of them, using your own Runners will get you are more stable and performant experience and also brings security advantages.
Instance Runners are shared for all users and project that want to use them. To target a shared Runner, tag your Pipeline with shared along with all the tags for features and capabilities you require for your pipeline to succeed. See below for an explanation of tags and what kind of Instance Runners are available.
If you don't configure a tag for your Pipeline, a runner configured to run untagged jobs will execute it. In my case, that will be the serverless runner, as it's great for quick and simple tasks and is available instantly. (It's also cheaper than to spin up an entire VM)
Docker-based Instance Runners usually share a cache which works across runners and pipeline runs. Runner where this is garuanteed to work are tagged with cache. Cached data will be available for 30 days, after which it will be automatically cleaned up. It's the perfect place for your node_moudles or rust dependencies.
Be aware that Cache is designed to reduce unnecessary bandwith or compute, not as a secure storage. If you need to share sensitive data between jobs, using artifacts is recommended, as they follow the projects security model, whereas the cache could potentially be read from other branches or merge requests and is not designed to be secure.
Tags allow you to fine tune what specifications the CI server should meet in order to execute your job. Please note that just because a tag exists, this doesn't mean that a runner is actually available. See below for a list of all shared Runners.
The following tags are available:
shared: A catchall for all shared instance runners. Just settings this tag means any available instance runner is fine (but could result in unexpected behaviour due to different architectures).
docker: A GitLab Runner using the docker executor, meaning that you can define an image in your Pipeline and expect this image to be used.
dind: Docker-in-Docker means that the docker executor has access to a docker daemon, meaning you can use the docker command inside your container to build an image. In non-dind executors, no docker socket is availabvle and thus your pipeline will error out when you try to use a docker command.
cache: Runner is able to load and update the distributed cache specified in your Pipeline.
amd64: The host CPU-architecture is amd64 (meaning 64bit based on AMDs design, x86-64 compatability). This is probably what you are running on your home desktop.
arm64: The host CPU-architecture is arm64 (alias Aarch64 or ARMv8+). This is the architecture of modern Macbooks and probably also your phone. YOu might experience problems with your build tools using this architecture and amd64 binaries do not work here (and vice-versa).
ipv4 / ipv6: Runner has either only ipv4, ipv6 or both if both tags present. Most ipv6-only runners have DNS64 configured to restore connectivity to most of the IPv4 internet, but you may still have issues if you depend on IPv4 access. If you have connection issues with downloading your dependencies, try adding the IPv4 tag.
A type is a collection of one or more runner using a specific set-up and feature set. Depending on your use-case, you might require different CPU architectures, permissions or executors.
This is the standard type of Instance Runner, suited for most jobs like building, testing and deploying. It provides a Docker-based hardened and secure environment with distributed cache and little overhead.
Runners of this type run untagged jobs as well. Feel free to use this Runner as much as you want!
Due to the hosts being non-ephemeral (i.e. persistent across multiple runs without being re-created), the hardened container runtime gVisor is used. Some advanced syscalls as well as Docker-in-Docker and even most rootless Docker image builders will not work here.
The following Runners are of the type Standard Constrained Instance Runner:
This runner operates on the free compute resources on Oracle Cloud.
Hosts: 2
israfel-alpha.ciisrafel-beta.ciSpecifications:
shared, shared-israfel, docker, cache, amd64, ipv4Hosts: Not fixed
This runner pools unitilized hosts with spare compute resources to serve as a GitLab Runner. It may very well be the case that no spare hosts are available and this runner therefor unavailable.
shared, shared-leliel, docker, cache, amd64, ipv4