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 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 enterprise scale in support of Ops Section Goals.
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. One of the identified strategic challenges along the way to realizing that vision is managing the balance between self-managed and GitLab.com product offerings. So, as is the case with the GitLab product strategy, the Runner three-year strategy must balance the requirements and projected evolution of both the SaaS and Self-Managed solutions.
So - why is that? In ten years (2030), we can reasonably forecast that a significant percentage of organizations will use GitLab SaaS as their value stream delivery platform compared to organizations that choose the self-managed option. However, there will continue to be a subset of organizations that will require a self-managed solution. There will also be a percentage of customers who use a hybrid solution, i.e., GitLab SaaS with self-hosted runners.
Today, 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.
We can make at least one fundamental forecast that is likely to be accurate based on the computing industry's historical evolution. In 2030, much like today, there will continue to be several computing platforms and architectures used in the computing industry. And so, to enable the GitLab product vision, GitLab Runner must continue to evolve and seamlessly support the market-leading computing technologies, machine architectures, and container orchestration platforms.
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.
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:
This category is already at the "Lovable" maturity level (see our definitions of maturity levels). However, we must 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 at scale. Besides working on the long-term vision, we continuously assess and prioritize working on issues opened by the community and customers in each release.
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 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 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.
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.
