2022 Update - GitLab.com SaaS Runners has evolved since the time of this blog post. See the up-to-date documentation on the SaaS Runners fleet for Linux, Windows, and Mac.
Not only is Continuous Integration built-in with GitLab CE and EE,
but we also offer Shared Runners to run your builds in CI for
free on GitLab.com. Up until recently, you may have experienced a short wait
time as your build got queued for a shared runner. With the latest release of
GitLab Runner 1.1, we've introduced autoscaling to help us meet
the growing demand, and this is now available on GitLab.com. Less waiting, more
building!
Scaling the service
Projects hosted in GitLab can have CI tasks defined in their .gitlab-ci.yml
files. These tasks are performed
by runners which are essentially virtual machines which run
your builds in Docker containers. These machines can run any of your builds that
are compatible with Docker.
On other platforms, similar functionality is only available with an add-on
charge. In GitLab it's free to connect your own runners, and we also began
offering free Shared Runners on GitLab.com. That means Shared
Runners are freely available for projects on GitLab.com, whether they are
private or public. However, up until recently users would have noticed their
builds would be queued to run as they waited for a shared runner to become
available for work.
Today we are extending our offering, enabling the recently announced
autoscaling feature. This will reduce the build times and also reduce the time
required to allocate a new available machine.
As of today, the Shared Runners for GitLab.com use the new GitLab Runner 1.1.
GitLab Runner is configured in autoscaling mode with distributed cache and
Docker registry proxy for Docker images.
Using Shared Runners
You will be able to continue using the Shared Runners for testing and deploying
your private projects.
The Shared Runners will continue to be used to build your static pages that
are served by GitLab Pages.
The machines
All your builds run on Digital Ocean 4GB
instances, with CoreOS and the latest Docker Engine installed.
Your builds will always be run on fresh machines. This will effectively
eliminate possible security issues, as there is no potential of breaking
out of the container.
The tags
All Shared Runners are tagged with shared, docker and linux.
You can use these tags in your .gitlab-ci.yml file to limit which runners are
used for specific jobs:
test:
...
tags:
- shared
deploy:
...
tags:
- my_private_runner
The above script will configure GitLab to always run your tests on shared
runners, and run deployments only on your specific runner, registered with
a my_private_runner tag.
What has changed
Previously, runners were configured to always start the mysql, postgres,
redis, and mongodb services.
However, we are aware that most of our users don't need to use all (or even any)
of these services, and have removed them from the default configuration.
If your builds do require one or more of these services, your builds may start
to fail unexpectedly. Modify your .gitlab-ci.yml file to add the services
required by your application:
services:
- mysql
- postgres
- redis
- mongodb
tests:
script: run-my-tests
...
Final configuration
You may be interested what GitLab Runner config.toml looks like.
It's really simple!
[[runners]]
name = "docker-auto-scale"
limit = X
url = "https://gitlab.com/ci"
token = "SHARED_RUNNER_TOKEN"
executor = "docker+machine"
[runners.docker]
image = "ruby:2.1"
privileged = false
volumes = ["/cache", "/usr/local/bundle/gems"]
[runners.machine]
IdleCount = 20
IdleTime = 1800
MaxBuilds = 1
MachineDriver = "digitalocean"
MachineName = "machine-%s-digital-ocean-4gb"
MachineOptions = [
"digitalocean-image=coreos-beta",
"digitalocean-ssh-user=core",
"digitalocean-access-token=DIGITAL_OCEAN_ACCESS_TOKEN",
"digitalocean-region=nyc2",
"digitalocean-size=4gb",
"digitalocean-private-networking",
"engine-registry-mirror=http://IP_TO_OUR_REGISTRY_MIRROR"
]
[runners.cache]
Type = "s3"
ServerAddress = "IP_TO_OUR_CACHE_SERVER"
AccessKey = "ACCESS_KEY"
SecretKey = "ACCESS_SECRET_KEY"
BucketName = "runner"
The above configuration says that the VM will be used only once, making your builds secure.
We will always have 20 machines waiting to pick up a new build.
We use Digital Ocean 4GB machine in NYC2, with CoreOS Beta and Docker 1.9.1 installed.
The runner is configured to use Docker Hub Registry Mirror and Distributed runners caching.
Happy building!
Live webcast: GitLab CI
Sign up for our webcast on April 14th, which includes an overview and tutorial
about using GitLab CI. Join to meet with the GitLab CI team and get your questions
answered live!
- Date: Thursday, April 14, 2016
- Time: 5pm (17:00) UTC; 12pm EST; 9am PST
- Register here
Can't make it? Register anyway, and we'll send you a link to watch it later!
