Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Runner

Vision

Our vision for GitLab Runner, in support of the Ops section goals, is to offer DevOps teams a build agent that works seamlessly on tomorrow's market-leading computing platforms and the tools to eliminate CI build fleet operational complexity at an enterprise scale.

To better understand GitLab Runner's vision, let's discuss how this aligns with the GitLab product vision and strategy and considers the realities of the broader computing and technology landscape. At GitLab, our product vision is to replace DevOps toolchains with a single application that is pre-configured to work by default across the entire DevOps lifecycle.

So while we will continue to invest a significant percentage of our engineering efforts on the GitLab SaaS Runners, we will also have to balance that investment with capabilities for self-managed runners. Why? Well, the reality of the computing landscape means that a subset of customers will continue to require self-managed runners that can execute Ci workloads on computing architectures not offered on GitLab SaaS.

GitLab Runner is distributed as a binary or container image. Customers can deploy and host a fleet of runners on public cloud or on-premise infrastructure. Several machine architectures, including Intel (x86-64), ARM (ARM64), IBM z-series, and host operating systems, Linux, Windows Server, macOS, are supported. Industry watchers forecast that based on current trends, containers and microservices will dominate the technology landscape in the 2020s, with Kubernetes the platform of choice for container orchestration. Of course, innovation and technology shifts can happen at any time, so we should anticipate that future technology solutions may change the market dynamics.

And so, to enable the GitLab product vision for GitLab SaaS, we must continue to deliver a highly available and performant CI build environment (runners). For self-managed, GitLab Runner must continue to evolve and seamlessly support the market-leading computing technologies, machine architectures, and container orchestration platforms. Finally, GitLab Runner must be at the forefront of delivering a 100% serverless build agent solution.

Direction overview

Runner Product Development Categories

The Runner product development strategy comprises three main focus areas to enable the vision.

  1. Runner Core: features and capabilities for the open-source GitLab Runner CI execution agent.
  2. Runner Cloud: hosted GitLab Runners available on GitLab SaaS and that support the GitLab Build Cloud for Linux, Windows and macOS.
  3. Runner Enterprise Management: features and capabilities for installing, configuring, managing and monitoring a fleet of GitLab Runners.

Top Vision Item(s)

The content in this section outlines some of the initiatives that we are exploring. In some cases, we are in the early phases of exploring the concept, while in others, we have a more concrete solution in mind and have started work on the first iteration of features or capabilities.

Runner Core

Runner Cloud

Runner Enterprise Management

What's Next & Why

In the section below, we highlight a few notable features that we are working to deliver in the near term releases.

Runner Core

Refer to this issue list for a more in-depth view of the Runner backlog for runner core. You can also filter by milestone to get a better sense of which issues are candidates for shipping in a release. This view includes additional details such as deprecations, technical debt, and bug fixes, providing a more comprehensive view of the active workstream.

Runner Cloud

Who we are focusing on?

Check out our Ops Section Direction "Who's is it for?" for an in depth look at the our target personas across Ops. For Runner, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:

  1. Devon - DevOps Engineer
  2. Sasha - Software Developer
  3. Delaney - Development Team Lead
  4. Priyanka - Platform Engineer

Maturity Plan

Competitive Landscape

When you run a continuous integration pipeline job or workflow, it is powered by some computing platform - this commonly includes a container, a physical desktop computer, a bare-metal server, or a virtual machine environment. A CI/CD agent is the software that is responsible for executing the scripts defined in a continuous integration pipeline job or workflow. There is the GitLab Runner, Jenkins agent, Github runner, Azure Pipelines agents, Drone.io runners, Codefresh Runner, to name a few.

In short, the GitLab Runner takes a job from a GitLab instance, executes that job, and sends the results back to GitLab, all over HTTPS.

So, given the seemingly simple CI job execution task, should we even consider the runner from a competitive analysis standpoint? The answer is yes, for as you can see from the few examples below, the industry recognizes that the CI engine's capabilities are critical to a value stream delivery platform's long-term success in the market.

In GitHub's 2021 Roadmap, we are seeing several runner related features including:

  1. Multiple Hosted Runner Sizes
  2. Enterprise Server can use Actions hosted runners
  3. Customization and security for GitHub.com hosted runners

Our perspective is that GitLab Runner Core is well-positioned to enable GitLab's strategic vision. Why?

  1. GitLab Runner is open-source. Our community members and customers have full access to the GitLab Runner source code and can contribute features, bug fixes directly to the code base.
  2. GitLab Runner supports multiple executors. One of the most useful executor types is the Docker executor, which enables users to execute CI jobs inside a container, resulting in less maintenance for the CI/CD build environment.
  3. GitLab Runner includes autoscaling out of the box. Autoscaling is available for public cloud virtual machines or Kubernetes stacks by using the Kubernetes executor. For a some a look at the competitive landscape of Autoscaling see gitlab&2502.
  4. GitLab Runner supports several computing architectures. Customers who need to self-host runners on platforms such as IBM Z mainframes to take advantage of GitLab and modern Value Stream Delivery Platforms can. We aim to meet and support customers on the platforms that they use in their environment.

SaaS Build Agents

Users of SaaS hosted CI platforms, such as GitLab.com, CircleCI, and GitHub, Azure DevOps can run their CI pipelines and get to a first green build without being concerned about the agents' setup and maintenance. Like GitLab, these providers are managing the build agents and the infrastructure that those agents run on.

GitLab Runner is a lightweight, high performant build agent that executes CI jobs in the cloud very efficiently. The performance of CI jobs, measured in job duration minutes, on GitLab.com hosted runners relative to the market is very comparable. The one variable is the computing resources allocated to the virtual machines hosting the build agents.

Today competitors such as GitHub, CircleCI, and Azure DevOps offer multiple virtual machine types for build agents hosted on Linux, macOS, or Windows virtual machines. GitLab offers one machine type for both Linux and Windows virtual machines. However, users on GitLab.com can install their own GitLab runners on a supported computing platform and use those runners to execute the CI jobs in their GitLab.com hosted project repository.

Self-Managed Build Agents

For users who need to host and manage their own build agents and the underlying infrastructure, GitLab runner offers a wide array of solutions positioned very well in the market place from a competitive standpoint. First, GitLab Runner binaries are available on x86, AMD64, ARM64, ARM, s390x (IBM-Z mainframes). Linux, Windows, and macOS operating systems are fully supported.

A significant competitive differentiator is the availability of the GitLab Runner custom executor. This open-source solution enables the community to add an executor to the GitLab Runner to execute CI jobs on a computing platform or infrastructure that's not currently supported. With this very powerful yet simple to implement driver, users can configure the GitLab Runner to use an executable to provision, run and clean up a build environment.

GitLab Runner is also available as a container image on DockerHub. Judging by the hundreds of thousands of daily downloads, this is a top-rated solution for users.

Customers hosting build agents on public cloud virtual machines can quickly deploy and use the GitLab Runner autoscaling feature. This autoscaling solution enables the automated provisioning and decommissioning of build agents based on CI job load.

Other DevOps solutions, such as onedev, have relied solely on Kubernetes to execute CI jobs with Linux and Windows containers support. From a GitLab Runner perspective, we have a complete Kubernetes offering with the GitLab Runner Kubernetes executor. And in fact, we see the Kubernetes executor as a critical strategic pillar for Runner Core.

Investment Focus

Top Customer Issue(s)

The list below represents issues that have a high number of upvotes from the community. To understand if an issue is targeted for delivery, review the target milestone and issue state labels. Refer to the interpreting issue states section of the handbook for additional guidance.

Give Feedback

The near term features and capabilities highlighted here represent just a subset of the features and capabilities that have been requested by the community and customers. If you have questions about a specific runner feature request or have a requirement that's not yet in our backlog, you can provide feedback or open an issue in the GitLab Runner repository.

Revision Date

This direction page was revised on: 2021-09-06

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license