The following page contains information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
GitLab Runner is the multi-platform agent that works with GitLab CI to execute the jobs in a pipeline and powers the CI build platform on GitLab.
Our vision for GitLab Runner is to offer DevOps teams a build agent that works seamlessly on today's and tomorrow's market-leading computing platforms and the tools to eliminate CI build fleet operational complexity at enterprise scale.
DevOps teams may be managing hundreds of Runners, which may also mean offering different virtual machine configurations and sizes, which adds operational complexity. At the heart of the Runner vision, is that DevOps teams should not have to spend enormous amounts of time and effort deploying, configuring, and maintaining Runners.
As is the case with the GitLab product strategy, the Runner's strategy must consider and balance the needs of both self-managed and GitLab.com product offerings. Self-managed customers whose security and compliance requirements dictate that the entire DevOps toolchain runs within their private networks can host the runner themselves. In addition to public clouds, self-managed customers can deploy and host the runner on several platforms, including Kubernetes, RedHat OpenShift, and Linux on Z for IBM Z mainframes. Therefore, the product strategy for self-managed assumes a future, much like today, where there will continue to be a wide variety in the type of infrastructure stacks organizations adopt on public clouds or deploy in their data centers.
The Runner product development strategy comprises three main focus areas to enable the vision.
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.
For a more in-depth view of the issue backlog for Runner core, refer to the issue list.
In the section below, we highlight a few key features that we are working to deliver in the near term releases.
This category is already at the "Lovable" maturity level (see our definitions of maturity levels). However, it's important to us that we defend our lovable status and provide the most value to our user community. To that end, we continue to collect and analyze customer and community feedback to understand users' pain points with installing, managing, and using GitLab Runners. If you have any feedback that you would like to share, you can do so in this epic.
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. Any computing environment can host a continuous integration pipeline job or workflow.
As its typically referred to, the build agent determines if the pipeline job or workflow can run on a target computing platform. The build agent is also 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, to name a few.
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 an open-source, 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 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.
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.
GitLab Runner's support for Kubernetes and the recent addition of autoscaling capability for AWS ECS and Fargate makes the GitLab Runner a compelling option for enterprises considering which value stream delivery platform to deploy to support their digital transformation strategic goals.
For the CS team, the issue gitlab-runner#3121 where orphaned processes can cause issues with the runner in certain cases has been highlighted as generating support issues.
