Problem Validation:Sticky Runners and Intermediate Build Elements

Problem Statement

How can we increase the speed and efficiency of GitLab pipelines for large repositories with long build times and that create artifacts which are gigabytes in size, and must be made available to subsequent stages in the pipeline?

Customers want to ensure that their CI/CD pipelines execute reliably and in as short a time as possible and this means that source code, dependencies and compiled binaries are persisted and shared between stages of a pipeline. We have explored solving this problem with a new feature that would enable a user to run jobs on a Gitlab Runner that already has the objects it needs instead of having to fetch them for each stage of the pipeline. This solution, Sticky Runners, would enable the re-use of a Runner for subsequent stages of a pipeline.

Even though there have been ongoing discussions on this topic, the problem and MVC solution needed additional definitions. So the goal of taking this feature through the problem and validation solution cycle was to ensure that the problem and related use cases were clearly defined so that a viable MVC solution could be proposed and ultimately implemented.

The description in this issue is a summary of the Opportunity canvas

Screen_Shot_2020-01-08_at_8.19.04_PM

Customer

User Persona

  • Devon (DevOps Engineer)
  • Programming languages that may be used in the persona segment organization: Java, C++, Javascript
  • Other frameworks, libraries, or tooling that may be used in the persona segment organization: NodeJS, Gradle

For this opportunity canvas, the focus is on development languages with a compilation step. In other words, those languages that create temporary or intermediate files as part of the build process. These files are then required for other stages of the pipeline.

Type of CI/CD Pipelines:

1. Pipelines with long build times and large workspaces.

Generally customers with large/complex project repos and pipelines fit the profile of the type of customers that we will need for solution validation.

Example configuration

  • 50 specific GitLab Runners
  • Each build or pipelines has 10 sub-jobs (env setup, configuration, build phases, test phases)
  • each build can take up to 6 hours
  • each build can produce binaries of up to 300 GB

2. Multi-framework pipelines.

An example of a multi-framework pipeline.

  • Job 1: run a spell checker on website content in Node JS.
  • Job 2: run static website builder in Ruby.
  • Job 3: run test suite in Java
  1. Mono-repos (for example an Android project)

Pain

  • NodeJS example: The problem is resulting in (1) longer pipeline execution times and (2) more complex pipelines due to the inclusion of additional script blocks.

  • Ruby example: Customer’s pipeline includes a test on a branch that introduces a new Ruby gem (a format for distributing Ruby programs and libraries). The build stage executes on the first Runner, (installing the new gem), but subsequent stages execute on a different Runner which does not have the gem created from the previous stage until the artifact download is complete.

  • “It's a pain for big projects as we have a very long build (2 hours) and very large workspace (15Gb). The issue is that sources can be checked out on one (runner) machine, but build started on other (runner) machine (which does not have sources).”

  • Artifacts passing between stages. “It doesn't make any sense. I'm spending an hour for building and then I cannot use my build to deploy it.”

  • “Am I the only one around here that has 10 GB of artifacts and a 5 hour build time?"

Business Case

Reach

Our current thinking is that any user that is executing CI jobs on GitLab.com that generates large artifacts will benefit from a solution to this problem.

2.0 = High impact

Confidence

100% = High confidence

Effort

Team member Effort in weeks
PM 4
UX 2
Backend Engineer 4
Total 2.4 person months

Solution

  • Provide a solution where the user can specify that a pipeline is executed on the same Runner. For this solution the source code, dependencies and compiled binaries must be persisted locally and shared between stages.

  • Persisted locally: This means that there is a solution so that the Runner does not have to upload files (artifacts) created from previous stages to GitLab.com and download them again if the files are needed to be used in a subsequent stage.

  • The updated MVC proposal for the Runner is documented in the issue description.

Affinity Diagram:

  • Summary of customer interview feedback captured in an Affinity diagram that is in the Design Management page of this issue.
Edited by Darren Eastman