GitLab Runner is the multi-platform execution agent that works with GitLab CI to execute the jobs in your pipelines.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
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, z/OS, vSphere, and even custom in-house implementations can be implemented.
The following is a selection of some of the significant features that are on the near term roadmap:
Today, we provide shared Runners on GitLab.com with Linux. The Windows and Mac Shared Runners will provide our Windows and MacOS community users the tooling to build their projects on GitLab.com without needing to set up and maintain build machines.
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.
It's important to us that we defend our lovable status, though, so if you see any actual or potential gap please let us know in our public epic for this category.
Maturing the Windows executor is of particular importance as we improve our support for Windows across the board. There are a few issues we've identified as being critical to 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.
Additionally, although it is not implemented entirely by the Runner team, implementing Vault integration support in GitLab via gitlab#28321 is important.
Other popular issues include:
There are a few top internal customer issues that we're investigating :
As discussed on our CI/CD vision page, one of the themes in support of our long term vision and strategy is to provide speedy, reliable pipelines. A vital enabler of that goal is preventing hourly runner queue time spikes: gitlab-runner#7814. We have also set an FY20-Q4 OKR goal to get CI queue times under 1 minute. In addition, we will continue to focus on investigating and providing improvements for other Runner related performance issues to ensure that we are continuously delivering the performance that you need for your build jobs.
Also related to slowness is the important issue gitlab-runner#4513 which tracks general improvement to execution time.
This year, a vital strategic initiative is migrating away from Docker Machine for autoscaling. As of now, the approach that we have in mind is to continue to make the minimum viable changes to the Docker Machine autoscaler to support the current user community, while in parallel invest in the Kubernetes executor as the long term replacement solution.
To follow along, or add feedback to this critical topic, check out issue gitlab-runner#4338
Supporting GitLab runners on IBM z/OS for IBM mainframes, gitlab-runner#3263 is another issue that is gaining interest from the community. If this is of interest to you, please head over and join the conversation as we would love to get your feedback on this important vision item.
Other platforms of interest we're tracking, through support via the custom executor, include AWS Fargate (gitlab-runner#2792, ARM (gitlab-runner#2076 compatibility, and GitLab Runners on Google Cloud Run.
These 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.