Announcing GitLab CI 3.0

Announcing GitLab CI 3.0

We are excited to announce the release of GitLab CI 3.0, the latest version of our Continuous Integration system that connects with GitLab. This is a major redesign, reflecting our recent ideas of what a CI system should look like: a flexible architecture for distributed, isolated builds. GitLab CI 3.0 consists of two components: the coordinator and its runners

The Coordinator

The coordinator is a Rack app that can run on the sames server as your GitLab installation. It provides a status and management interface for all your builds. The coordinator manages the build queues for all the projects you have registered with it and assigns the builds to individual runners.

You can associate multiple runners to one CI project. This would allow you for example to have test suites running for two feature branches at the same time.

You can also associate secondary CI projects to a single GitLab project. We use this to run the test suite for gitlabhq on a machine running MySQL (the primary build) and on another one running PostgreSQL (the secondary build).

The Runners

A runner is a Ruby process that asks its coordinator for build jobs to perform. You can host a runner on a dedicated build server, a VM, a spare laptop, etc. One machine may host multiple runners. For example, you could use two runners on the same machine to build release packages and publish the static company website. On the other hand, runners can also be isolated. For instance, a runner that will publish your website may need special credentials. By isolating this runner in a trusted environment you can restrict access to the publishing credentials. The runner only needs to have network access to its coordinator and to your GitLab installation.

This is just the beginning

These are just a few of the possible uses and configurations of the new GitLab CI. We look forward to hearing your stories!