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

Category Direction - Runner

GitLab Runner

GitLab Runner is the multi-platform execution agent that works with GitLab CI to execute the jobs in your pipelines. Our vision is for Runners on GitLab.com to be the most full-featured, high-performant CI build fleet in the cloud.

Organizational Adoption Journey

graph LR classDef blue fill:#3278ca, color:#fff classDef darkblue fill:#225798, color:#fff subgraph "CUSTOMER JOURNEY" A0[User Actions]:::darkblue end subgraph "POC, ONBOARDING, PRODUCTION ENVIRONMENT SETUP" A1[Install GitLab]:::blue --> A2(Install the 1st Runner):::blue end subgraph "SCALE USAGE PHASE: USERS, FEATURES, STAGE ADOPTION, n...n+1 phases" A2 --> A3(Rollout and start managing more than 1 Runner to support the organization):::blue end A0-.-A1;
graph LR classDef red fill:#c92d39, color:#fff classDef darkred fill:#9a0814, color:#fff classDef blue fill:#3278ca, color:#fff classDef darkblue fill:#225798, color:#fff subgraph "CUSTOMER JOURNEY" A0[Runner Pain Points]:::darkred end subgraph "POC, ONBOARDING, PRODUCTION ENVIRONMENT SETUP" A1[Manual steps to install
and configure first Runner]:::red --> A2(Manual steps to configure additional Runners):::red end subgraph "SCALE USAGE PHASE: USERS, FEATURES, STAGE ADOPTION, n...n+1 phases" A2 --> A3[Runner Token registration
process is manual]:::red A3 --> A4[High operational overhead
to maintain a large fleet of Runners]:::red A4 --> A5[No instrumentation that
indicates why a Runner
has not started]:::red end A0-.-A1;

What's Next & Why

Multi-Platform Support

Make CI Easy for Self-Managed

Maturity Plan

Since this category is already at the "Lovable" maturity level (see our definitions of maturity levels), we do not have an upcoming target for bringing it to the next level. 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 are starting to work on collecting 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.

Maturing the Windows executor and autoscaler is of particular importance as we improve our support for Windows. There are a few issues we've identified as being part of that effort:

Competitive Landscape

The Runner is currently evaluated as part of the comprehensive competitive analysis in the Continuous Integration category

Top Customer Success/Sales Issue(s)

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.

Top Customer Issue(s)

The top requested customer issue that we are investigating is gitlab-runner#1809. The principal goal of this feature is to enable you to use variables declared in the .gitlab.yml file within other variables in that file.

Other popular issues include:

Top Internal Customer Issue(s)

Top Vision Item(s)

Migrating from Docker Machine for Runner Autoscaling

Autoscaling of GitLab Runner on Virtual Machines hosted on the major cloud platforms is done today with Docker Machine which is in maintenance mode. As such, a key strategic initiative is migrating away from Docker Machine for autoscaling. To follow along, or add feedback to this critical topic, please review the epic gitlab-org&2502.

Shared runner billing and management for self-managed

We are also exploring enabling users of self-managed GitLab instances (CE and EE) to purchase CI minutes, gitlab-org&835. This solution will also include management and reporting capability so that users can see a clear history of Runner minutes granted and consumed.

Offer Premium Machine Types in Shared Runner Fleet

We currently offer a single size for runners in our shared fleet, but some jobs take more or less CPUs, and some take more or less RAM. Offering additional options will help users who are not comfortable with or not interested in running their own runners.

To follow along, or add feedback to this critical topic, refer to Epic #2426

Additional Platforms

A common request we get is to add support for various platforms to the Runner. We've chosen to support the plethora of different systems out there by adding support for a custom executor that can be overridden to support different needs. In this way platforms like Lambda, vSphere, and even custom in-house implementations can be implemented.

There is high community interest from customers who have IBM z/OS Mainframe's and want to use GitLab Runners on that platform. To follow along, or add feedback to this critical topic, please review the epic Epic #3144.

Additional platforms are primarily being implemented through community contributions, so if you're interested in contributing to GitLab these issues are great ones to get involved with.

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