GitLab Runner is the multi-platform execution agent that works with GitLab CI to execute the jobs in your pipelines.
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 across the board. There are a few issues we've identified as being part of that effort:
The Runner is currently evaluated as part of the comprehensive competitive analysis in the Continuous Integration category
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 top requested customer issue that we are investigating is gitlab-runner#2797. The principal goal of this feature request is to enable the execution of a GitLab pipeline on a users' local system so that a developer is able to develop, test, and validate their CI pipelines quickly.
Other popular issues include:
There are a few top internal customer issues that we're investigating :
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
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.
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.
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.
Other platforms that we are investigating adding support for via the custom executor include Google Cloud Run. There is also high community interest from customers who have IBM z/OS Mainframe's and want to use GitLab Runners on that platform. Our goal for an MVC, z/OS Mainframe support for GitLab CI Runner, is to release a docker image with GitLab Runner for Linux on IBM Z.
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.
