Category Direction - Runner

1. 表示中のページ:
2. Category Direction - Runner

• GitLab Runner
• Organizational Adoption Journey
• Top Vision Item(s)
  • Runner Core
  • Runner Cloud
  • Runner Enterprise Management
• What's Next & Why
  • Runner Core
  • Runner Cloud
• Maturity Plan
• Competitive Landscape
• Top Customer Success/Sales Issue(s)
• Top Customer Issue(s)

GitLab Runner

GitLab Runner is the flexible, multi-platform execution agent that works with GitLab CI to execute the jobs in your pipelines and powers the CI build fleet on GitLab.com.

Our vision is to eliminate CI build fleet maintenance and operational complexity for DevOps teams.

Depending on the organization's size, DevOps teams may be managing hundreds of Runners. In some cases, that may also mean offering different virtual machine configurations and sizes, which adds operational complexity. So at the heart of this vision, the guiding principle is that DevOps teams should not have to spend enormous amounts of time and effort deploying, configuring, and maintaining Runners. As is the case with the GitLab product strategy, the Runner's product development strategy must consider and balance the needs of both self-managed and GitLab.com product offerings. Self-managed customers whose security and compliance requirements dictate that the entire DevOps toolchain runs within their private networks can host the Runner themselves. In addition to public clouds, self-managed customers can deploy and host the Runner on several platforms, including Kubernetes, RedHat OpenShift, and Linux on Z for IBM Z mainframes. The product strategy for self-managed assumes a future, much like today, where there will continue to be a wide variety in the type of infrastructure stacks organizations deploy and manage in their data centers.

• Issue List
• Overall Vision

Organizational Adoption Journey

The Runner product development strategy comprises three main focus areas to enable the vision.

1. Runner Core: features and capabilities for the open-source Runner CI execution agent.
2. Runner Cloud: the Runner CI build virtual machines available on GitLab SaaS.
3. Runner Enterprise Management: features and capabilities for DevOps teams that self-manage the Runner CI/CD build infrastructure.

Top Vision Item(s)

Runner Core

• Autoscaling replacement for Docker Machine: 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.
• 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 vSphere, and even custom in-house implementations can be implemented. 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.

Runner Cloud

• macOS Build Cloud (Runners) on GitLab.com Our goal is to provide customers a GitLab CI solution that delivers exceptional build speed and on-demand scale building applications for Apple products, including iPad, iPhone, Apple Watch, Apple TV, and Mac.
• Windows Runners on GitLab.com - GA In Q4FY20, we released the preview of Windows Runners on GitLab.com. We have seen a gradual increase in the adoption and use of this service. Additionally, there has been quite a bit of feedback and requests for enhancements. We plan to add a key feature, Windows autoscaler, which will enable the pre-provisioning of Windows VM's to process CI jobs more efficiently.
• Linux Runners: Offer multiple GCP VM types and sizes We currently offer a single VM type, (Google Cloud Platform n1-standard-1 ), for Linux Runners on GitLab.com. However, the execution duration of certain types of CI jobs can be reduced if they are executed on compute or memory optimized VM's, or general-purpose VM's with more vCPUs and RAM. Offering additional options will also help users who are not interested in managing their own Runners.
• GitLab.com Runners for Self-Managed (Runners-as-a-Service): We are also exploring offering to enable organizations to connect self-managed GitLab instances to Runners hosted and fully maintained by GitLab. If you are interested in providing feedback on this concept, you can add comments to this issue, gitlab#226819.

Runner Enterprise Management

• Make CI easy for Self-Managed GitLab users: Our goal is that users self-managed GitLab should be able to get up and running with CI with as little friction as possible.
• Runner Enterprise Management Dashboard: In the Runner Enterprise Management product category, we are starting to collect customer feedback on delivering a first-class enterprise management experience in the GitLab UI for organizations that manage hundreds of Runners.

What's Next & Why

In the section below, we highlight a few key features that we are working to deliver in the in the next few releases.

Runner Core

• Enable after_script to run even if the job is cancelled by the user in GitLab. In gitlab#15603, users will be able to include a new configuration option interruptible: graceful in a .gitlab-ci.yml file. When this configuration option, interruptible: graceful, is included in the pipeline, then after_script must be run. This is an essential feature for CI as, in some cases, it is necessary to run clean-up scripts even if the pipeline job has failed or canceled by the user.
• Support reading defined CI/CD secrets from Vault server. This feature adds support in the Runner to pull secrets into CI/CD job variables from Hashicorp Vault.
• Use variable inside other variable The principal goal of this feature is to enable users to use variables declared in the .gitlab.yml file within other variables in that file.

Runner Cloud

• macOS Build Cloud Runners on GitLab.com (Closed Beta) We have heard from several users and community members that need the ability to build macOS CI jobs on GitLab.com without having to set up and maintain self-managed macOS Runners. To address this need, we are working towards a closed beta launch of macOS Runners on GitLab.com.

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.

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)

• gitlab-runner#2797: Local runner execution MVC
• gitlab-runner#1057: Specify root folders for artifacts
• gitlab-runner#6400: Make environment variables set in before_script available for expanding in .gitlab-ci.yml
• gitlab-runner#1107: Docker Artifact caching
• gitlab-runner#3392: Multi-line command output can be un-collapsed in Job terminal output view
• gitlab-runner#3207: Configure docker volumes in .gitlab-ci.yml
• gitlab-runner#1797: Caching is very slow for Node.JS projects