The following page may contain 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.
| Stage | Verify |
| Maturity | Lovable |
| Content Last Reviewed | 2024-01-25 |
Thanks for visiting this direction page on the Runner Core category at GitLab. This page belongs to the Runner Group within the Verify Stage and is maintained by Darren Eastman.
GitLab Runner - the near-ubiquitous build agent that executes CI jobs on a target compute platform is a critical foundational pillar of GitLab's one DevSecOps platform vision. The fundamental problems customers must solve in this product category include installing, configuring, and scaling CI/CD build agents (runners) on public or private cloud infrastructure and securely executing CI/CD jobs on heterogeneous computing architectures, x86-64, ARM, and s390x.
For customers that run millions of CI/CD jobs monthly, the primary GitLab Runner autoscaling options for CI/CD builds in ephemeral, isolated environments are Kubernetes and autoscaling on public cloud or on-premise hosted virtual machine environments. Therefore, critical needs for this customer segment include consistently fast start times for builds, fast build times as measured by total wall clock time, low CI build failure rates due to runner or runner host infrastructure issues, and minimal operational overhead.
For other customer segments, critical needs include seamless support for multi-platform and architecture builds within the same GitLab CI/CD pipeline.
Our strategy for GitLab Runner is to provide a build agent that customers can easily use and manage, is supported on the market-leading compute architectures, has first-class support for autoscaling on Kubernetes, and built-in autoscaling on virtual machines or instances provided by the major cloud providers.
In calendar year 2024 our major investment themes for new features are as follows:
In the next three months (Feburary to April) we plan to deliver these features:
Next Runner Autoscaling:
General Runner Core Features:
General Runner Core Features:
An improved CI logs management experience for multi-line commands
Next Runner Autoscaling:
We are not actively working on the following features:
Runner Priority - This is a viral feature proposal in the Runner core product backlog. The problem is routing CI jobs to an available or less busy Runner. One use case that has come up recently in multiple customer conversations is being able to only burst into public cloud-hosted runners (cloud bursting), when the capacity of on-premise hosted runner infrastructure is at capacity. Using the public cloud for burst-only workloads is critical as it enables customers to keep their cloud spend for runner infrastructure to a minimum. We had decided not to work on a solution to this problem due to the complexity of architectural changes that may be required to the GitLab CI job queueing mechanism. However, recent customer interviews have highlighted how critical this problem is and the urgency of a solution for their expanded use of GitLab CI. Therefore the next step is a small iteration, the goal of which is to develop a proof-of-concept solution.
Sticky Runners - For this feature, the problem to solve is that users need to improve CI job performance in scenarios where each job can generate intermediate build elements with hundreds of GBs in size. In the current GitLab CI model, a significant amount of pipeline execution time is due to the uploading and downloading of intermediate build elements between jobs in a pipeline. Given the current Runner executor implementation, i.e., we support several executor types out of the box (shell, docker, Kubernetes), changing the CI job execution paradigm in GitLab is a significant architectural change. The Sticky Runners MVC feature is not in the near-term roadmap due to higher priority features in the Runner core and the Verify stage.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
When you run a continuous integration pipeline job or workflow, the code in that pipeline must execute on some computing platform to complete your software's building, testing, and deployment. Terms used to describe the software that handles the pipeline code execution include worker, agent, or runner.
So while the basic functionality of pipeline code execution is table stakes in the industry, the ability to efficiently build software on multiple compute platforms with low operational maintenance overhead are critical features for a best-in-class solution.
.gitlab-ci.yml file provides a declarative syntax for defining jobs, stages, and dependencies, making it easy for developers to set up and manage their pipelines.| Solution | CI/CD Agent naming convention/brand | Self-Managed Option Availablity | Notes |
|---|---|---|---|
| GitHub Actions | Runners | Available | At its core, GitHub Action Runners are similar to GitLab Runners in that they communicate to a central server via a REST API, execute jobs, and send the logs and artifacts back to the server when finished. However, multi-platform support, native autoscaling on cloud instances, support for Kubernetes as a build environment, concurrency, and parallel CI/CD job execution are more mature in GitLab Runner. As expected, GitHub has continued to invest in features and capabilities to improve the maturity of GitHub Action Runners. For instance, the recently released Actions Runner Controller (ARC) enables GitHub Actions Runners to autoscale on Kubernetes clusters. However, as noted by others, there is operational overhead involved in the setup and configuration of ARC. On the GitHub public roadmap, we also notice similar investment themes regarding multi-platform support as GitHub continues to target market segments requiring a self-managed platform. |
| Jenkins | Agents | Available | In Jenkins, an agent is a software executable that runs a task under the direction of the Jenkins controller. Like GitLab Runner, a Jenkins agent can run on different computing environments (bare metal, virtual machines, containers, Kubernetes clusters). Java must be supported and installed on the host OS to run a Jenkins agent. |
| Harness.io | Harness Delegate | Available | Harness currently provides the following types of Delegate: Kubernetes, Shell Script, AWS ECS, Helm, Docker. Though the Delegates perform a similar essential function as GitLab Runner, i.e., executes tasks provided by the Harness Manager, the Delegates' primary purpose is to deploy software to the target platform. In this regard, the value proposition of the GitLab Agent for Kubernetes is a critical consideration when evaluating capabilities in GitLab for developer frictionless cloud-native deployment. |