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.
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.
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.
In the section below, we highlight a few notable features that we are working to deliver in the near term releases.
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.
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:
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:
Our perspective is that GitLab Runner Core is well-positioned to enable GitLab's strategic vision. Why?
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.
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.
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.
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.
This direction page was revised on: 2021-09-06
