The GitLab Runner is our 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 recently 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 supported in the runner for your needs.
Up next is adding interactive web terminal support for the Runner into the Helm Chart (gitlab-runner#3859). This will help more users take advantage of this great feature.
At the same time we are working on making the runner extensible, introducing a shim for the core runner capabilites via gitlab-runner#2885 which will make it possible for teams to support alternative provisioning models, archictures, and for runtime injection of behaviors into the runner.
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. 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:
For the moment, the Runner is 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.
We have a few top issues that we're investigating:
0000We have an issue with timeouts not working that is causing issues for several users (gitlab-runner#4147), and it is on our agenda to resolve.
We frequently receive requests for supporting different provisioning platforms and architectures in the runner - we haven't been able to support these because each combination brings in additional requirements for testing and maintenance. Instead, we want to enable people to build their own integration steps into the runner in a safe way. Through introducing a shim for the core runner capabilites in gitlab-runner#2885 we make this possible for our users.
Additionally, supporting prioritization of runners via gitlab-ce#63860 could be very powerful. For example, you could have multiple runners but have a few more powerful ones that you want to be selected first if they are available.
