@@ -14,7 +14,7 @@ There are two tokens to take into account when connecting a runner with GitLab.
| Token | Description |
| ----- | ----------- |
| Registration token | Token used to [register the runner](https://docs.gitlab.com/runner/register/). It can be [obtained through GitLab](../ci/runners/README.md). |
| Registration token | Token used to [register the runner](https://docs.gitlab.com/runner/register/). It can be [obtained through GitLab](../ci/runners/index.md). |
| Authentication token | Token used to authenticate the runner with the GitLab instance. It is obtained either automatically when [registering a runner](https://docs.gitlab.com/runner/register/), or manually when [registering the runner via the Runner API](#register-a-new-runner). |
Here's an example of how the two tokens are used in runner registration:
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type:reference
redirect_to:'index.md'
---
# GitLab SaaS runners
This document was moved to [another location](index.md).
If you are using self-managed GitLab or you want to use your own runners on GitLab.com, you can
[install and configure your own runners](https://docs.gitlab.com/runner/install/).
If you are using GitLab SaaS (GitLab.com), your CI jobs automatically run on shared runners. No configuration is required.
Your jobs can run on [Linux](#linux-shared-runners) or [Windows](#windows-shared-runners-beta).
The number of minutes you can use on these shared runners depends on your
which depends on your [subscription plan](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes).
## Linux shared runners
Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
**time out after 3 hours**, regardless of the timeout configured in a
project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
demonstrates how you might use a pre-clone step to seed the build
directory.
### `config.toml`
The full contents of our `config.toml` are:
NOTE:
Settings that are not public are shown as `X`.
**Google Cloud Platform**
```toml
concurrent=X
check_interval=1
metrics_server="X"
sentry_dsn="X"
[[runners]]
name="docker-auto-scale"
request_concurrency=X
url="https://gitlab.com/"
token="SHARED_RUNNER_TOKEN"
pre_clone_script="eval \"$CI_PRE_CLONE_SCRIPT\""
executor="docker+machine"
environment=[
"DOCKER_DRIVER=overlay2",
"DOCKER_TLS_CERTDIR="
]
limit=X
[runners.docker]
image="ruby:2.5"
privileged=true
volumes=[
"/certs/client",
"/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro"# Make kaniko builds work on GCP.
]
[runners.machine]
IdleCount=50
IdleTime=3600
MaxBuilds=1# For security reasons we delete the VM after job has finished so it's not reused.
MachineName="srm-%s"
MachineDriver="google"
MachineOptions=[
"google-project=PROJECT",
"google-disk-size=25",
"google-machine-type=n1-standard-1",
"google-username=core",
"google-tags=gitlab-com,srm",
"google-use-internal-ip",
"google-zone=us-east1-d",
"engine-opt=mtu=1460",# Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
"engine-opt=ipv6",# This will create IPv6 interfaces in the containers.
"engine-opt=fixed-cidr-v6=fc00::/7",
"google-operation-backoff-initial-interval=2"# Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
]
[[runners.machine.autoscaling]]
Periods=["* * * * * sat,sun *"]
Timezone="UTC"
IdleCount=70
IdleTime=3600
[[runners.machine.autoscaling]]
Periods=["* 30-59 3 * * * *","* 0-30 4 * * * *"]
Timezone="UTC"
IdleCount=700
IdleTime=3600
[runners.cache]
Type="gcs"
Shared=true
[runners.cache.gcs]
CredentialsFile="/path/to/file"
BucketName="bucket-name"
```
## Windows shared runners (beta)
The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
and shouldn't be used for production workloads.
During this beta period, the [shared runner pipeline quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
applies for groups and projects in the same manner as Linux runners. This may
change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
Windows shared runners on GitLab.com autoscale by launching virtual machines on
developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with
2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
We want to keep iterating to get Windows shared runners in a stable state and
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type:reference
---
# GitLab SaaS runners
If you are using self-managed GitLab or you want to use your own runners on GitLab.com, you can
[install and configure your own runners](https://docs.gitlab.com/runner/install/).
If you are using GitLab SaaS (GitLab.com), your CI jobs automatically run on shared runners. No configuration is required.
Your jobs can run on [Linux](#linux-shared-runners) or [Windows](#windows-shared-runners-beta).
The number of minutes you can use on these shared runners depends on your
which depends on your [subscription plan](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes).
## Linux shared runners
Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
**time out after 3 hours**, regardless of the timeout configured in a
project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
demonstrates how you might use a pre-clone step to seed the build
directory.
### `config.toml`
The full contents of our `config.toml` are:
NOTE:
Settings that are not public are shown as `X`.
**Google Cloud Platform**
```toml
concurrent=X
check_interval=1
metrics_server="X"
sentry_dsn="X"
[[runners]]
name="docker-auto-scale"
request_concurrency=X
url="https://gitlab.com/"
token="SHARED_RUNNER_TOKEN"
pre_clone_script="eval \"$CI_PRE_CLONE_SCRIPT\""
executor="docker+machine"
environment=[
"DOCKER_DRIVER=overlay2",
"DOCKER_TLS_CERTDIR="
]
limit=X
[runners.docker]
image="ruby:2.5"
privileged=true
volumes=[
"/certs/client",
"/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro"# Make kaniko builds work on GCP.
]
[runners.machine]
IdleCount=50
IdleTime=3600
MaxBuilds=1# For security reasons we delete the VM after job has finished so it's not reused.
MachineName="srm-%s"
MachineDriver="google"
MachineOptions=[
"google-project=PROJECT",
"google-disk-size=25",
"google-machine-type=n1-standard-1",
"google-username=core",
"google-tags=gitlab-com,srm",
"google-use-internal-ip",
"google-zone=us-east1-d",
"engine-opt=mtu=1460",# Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
"engine-opt=ipv6",# This will create IPv6 interfaces in the containers.
"engine-opt=fixed-cidr-v6=fc00::/7",
"google-operation-backoff-initial-interval=2"# Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
]
[[runners.machine.autoscaling]]
Periods=["* * * * * sat,sun *"]
Timezone="UTC"
IdleCount=70
IdleTime=3600
[[runners.machine.autoscaling]]
Periods=["* 30-59 3 * * * *","* 0-30 4 * * * *"]
Timezone="UTC"
IdleCount=700
IdleTime=3600
[runners.cache]
Type="gcs"
Shared=true
[runners.cache.gcs]
CredentialsFile="/path/to/file"
BucketName="bucket-name"
```
## Windows shared runners (beta)
The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
and shouldn't be used for production workloads.
During this beta period, the [shared runner pipeline quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
applies for groups and projects in the same manner as Linux runners. This may
change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
Windows shared runners on GitLab.com autoscale by launching virtual machines on
developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with
2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
We want to keep iterating to get Windows shared runners in a stable state and
If you want to use a MySQL container, you can use [GitLab Runner](../runners/README.md) with the Docker executor.
If you want to use a MySQL container, you can use [GitLab Runner](../runners/index.md) with the Docker executor.
This example shows you how to set a username and password that GitLab uses to access the MySQL container. If you do not set a username and password, you must use `root`.
...
...
@@ -130,5 +130,5 @@ GitLab Runner with the Shell executor.
## Example project
To view a MySQL example, create a fork of this [sample project](https://gitlab.com/gitlab-examples/mysql).
This project uses publicly-available [shared runners](../runners/README.md) on [GitLab.com](https://gitlab.com).
This project uses publicly-available [shared runners](../runners/index.md) on [GitLab.com](https://gitlab.com).
Update the README.md file, commit your changes, and view the CI/CD pipeline to see it in action.
