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.
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:
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#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:
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.
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
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.
