• Overview
  • Pipelines for Merge Requests
    • Documentation only MR pipeline
    • Code-only MR pipeline
    • Frontend-only MR pipeline
    • QA-only MR pipeline
  • Fail-fast pipeline in Merge Requests
    • Determining related test files in a Merge Request
  • RSpec minimal job experiment
    • Findings
  • PostgreSQL versions testing
    • Current versions testing
    • Long-term plan
  • Test jobs
  • Review app jobs
  • As-if-FOSS jobs
• Performance
  • Interruptible pipelines
  • Caching strategy
  • Artifacts strategy
  • Pre-clone step
• CI configuration internals
  • Stages
  • Default image
  • Dependency Proxy
  • Default variables
  • Common job definitions
  • rules, if: conditions and changes: patterns
    • if: conditions
    • changes: patterns

Pipelines for the GitLab project

Pipelines for gitlab-org/gitlab and gitlab-org/gitlab-foss (as well as the dev instance’s mirrors) are configured in the usual .gitlab-ci.yml which itself includes files under .gitlab/ci/ for easier maintenance.

We’re striving to dogfood GitLab CI/CD features and best-practices as much as possible.

Overview

Pipelines for the GitLab project are created using the workflow:rules keyword feature of the GitLab CI/CD.

Pipelines are always created for the following scenarios:

• main branch, including on schedules, pushes, merges, and so on.
• Merge requests.
• Tags.
• Stable, auto-deploy, and security branches.

Pipeline creation is also affected by the following CI/CD variables:

• If $FORCE_GITLAB_CI is set, pipelines are created.
• If $GITLAB_INTERNAL is not set, pipelines are not created.

No pipeline is created in any other cases (for example, when pushing a branch with no MR for it).

The source of truth for these workflow rules is defined in .gitlab-ci.yml.

Pipelines for Merge Requests

In general, pipelines for an MR fall into one or more of the following types, depending on the changes made in the MR:

• Documentation only MR pipeline: This is typically created for an MR that only changes documentation.
• Code-only MR pipeline: This is typically created for an MR that only changes code, either backend or frontend.
• Frontend-only MR pipeline: This is typically created for an MR that only changes frontend code.
• QA-only MR pipeline: This is typically created for an MR that only changes end to end tests related code.

We use the rules: and needs: keywords extensively to determine the jobs that need to be run in a pipeline. Note that an MR that includes multiple types of changes would have a pipelines that include jobs from multiple types (e.g. a combination of docs-only and code-only pipelines).

Documentation only MR pipeline

Reference pipeline:

Code-only MR pipeline

Reference pipeline

Frontend-only MR pipeline

Reference pipeline:

QA-only MR pipeline

Reference pipeline:

Fail-fast pipeline in Merge Requests

To provide faster feedback when a Merge Request breaks existing tests, we are experimenting with a fail-fast mechanism.

An rspec fail-fast job is added in parallel to all other rspec jobs in a Merge Request pipeline. This job runs the tests that are directly related to the changes in the Merge Request.

If any of these tests fail, the rspec fail-fast job fails, triggering a fail-pipeline-early job to run. The fail-pipeline-early job:

• Cancels the currently running pipeline and all in-progress jobs.
• Sets pipeline to have status failed.

For example:

A Merge Request author may choose to opt-out of the fail fast mechanism by doing one of the following:

• Including [SKIP RSPEC FAIL-FAST] in the Merge Request title.
• Starting the dont-interrupt-me job found in the sync stage of a Merge Request pipeline.

The rspec fail-fast is a no-op if there are more than 10 test files related to the Merge Request. This prevents rspec fail-fast duration from exceeding the average rspec job duration and defeating its purpose.

This number can be overridden by setting a CI/CD variable named RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD.

Determining related test files in a Merge Request

The test files related to the Merge Request are determined using the test_file_finder gem. We are using a custom mapping between source file to test files, maintained in the tests.yml file.

RSpec minimal job experiment

As part of the objective to improve overall pipeline duration, we are experimenting with a minimal set of RSpec tests. The purpose of this experiment is to verify if we are able to run a minimal set of RSpec tests in a Merge Request pipeline, without resulting in increased number of broken main branch.

To identify the minimal set of tests needed, we use Crystalball gem to create a test mapping. The test mapping contains a map of each source files to a list of test files which is dependent of the source file. This mapping is currently generated using a combination of test coverage tracing and a static mapping. In the detect-tests job, we use this mapping to identify the minimal tests needed for the current Merge Request.

In this experiment, each rspec job is accompanied with a minimal version. For example, rspec unit job has a corresponding rspec unit minimal job. During the experiment, each Merge Request pipeline will contain both versions of the job, running in parallel.

To illustrate this:

The result of both set of jobs in the pipeline is then compared to identify any false positive. A list of such pipeline can be found in Sisense.

A false positive is defined as a pipeline where the minimal jobs passed, but the non-minimal jobs failed. This indicates that the changeset resulted in a test failure, which was not detected by the minimal jobs. Consequently, this signifies a gap in the test mapping used, which would need to be rectified.

Findings

After a round of the experiment done in December 2020, we discovered that it was challenging to achieve a mapping that gives high confidence at the moment, because of 2 reasons:

• Each identified gap in the test mapping is unique, each needing its own investigation and improvement to the creation of the test mapping.
• There is a large number of flaky tests which added a lot of noise in the data, slowing down the investigation process.

PostgreSQL versions testing

Our test suite runs against PG12 as GitLab.com runs on PG12 and Omnibus defaults to PG12 for new installs and upgrades, Our test suite is currently running against PG11, since GitLab.com still runs on PG11.

We do run our test suite against PG11 on nightly scheduled pipelines as well as upon specific database library changes in MRs and main pipelines (with the rspec db-library-code pg11 job).

Current versions testing

Long-term plan

We follow the PostgreSQL versions shipped with Omnibus GitLab:

Test jobs

Consult GitLab tests in the Continuous Integration (CI) context for more information.

We have dedicated jobs for each testing level and each job runs depending on the changes made in your merge request. If you want to force all the RSpec jobs to run regardless of your changes, you can include RUN ALL RSPEC in your merge request title.

Review app jobs

Consult the Review Apps dedicated page for more information.

As-if-FOSS jobs

The * as-if-foss jobs allows the GitLab test suite “as-if-FOSS”, meaning as if the jobs would run in the context of the gitlab-org/gitlab-foss project. These jobs are only created in the following cases:

• gitlab-org/security/gitlab merge requests.
• Merge requests which include RUN AS-IF-FOSS in their title.
• Merge requests that changes the CI configuration.

The * as-if-foss jobs are run in addition to the regular EE-context jobs. They have the FOSS_ONLY='1' variable set and get their EE-specific folders removed before the tests start running.

The intent is to ensure that a change doesn’t introduce a failure after the gitlab-org/gitlab project is synced to the gitlab-org/gitlab-foss project.

Performance

Interruptible pipelines

By default, all jobs are interruptible, except the dont-interrupt-me job which runs automatically on main, and is manual otherwise.

If you want a running pipeline to finish even if you push new commits to a merge request, be sure to start the dont-interrupt-me job before pushing.

Caching strategy

1. All jobs must only pull caches by default.
2. All jobs must be able to pass with an empty cache. In other words, caches are only there to speed up jobs.
3. We currently have several different cache definitions defined in .gitlab/ci/global.gitlab-ci.yml, with fixed keys:
   • .setup-test-env-cache
   • .rails-cache
   • .static-analysis-cache
   • .coverage-cache
   • .danger-review-cache
   • .qa-cache
   • .yarn-cache
   • .assets-compile-cache (the key includes ${NODE_ENV} so it’s actually two different caches).
4. These cache definitions are composed of multiple atomic caches.
5. Only the following jobs, running in 2-hourly scheduled pipelines, are pushing (i.e. updating) to the caches:
   • update-setup-test-env-cache, defined in .gitlab/ci/rails.gitlab-ci.yml.
   • update-gitaly-binaries-cache, defined in .gitlab/ci/rails.gitlab-ci.yml.
   • update-static-analysis-cache, defined in .gitlab/ci/rails.gitlab-ci.yml.
   • update-qa-cache, defined in .gitlab/ci/qa.gitlab-ci.yml.
   • update-assets-compile-production-cache, defined in .gitlab/ci/frontend.gitlab-ci.yml.
   • update-assets-compile-test-cache, defined in .gitlab/ci/frontend.gitlab-ci.yml.
   • update-yarn-cache, defined in .gitlab/ci/frontend.gitlab-ci.yml.
   • update-storybook-yarn-cache, defined in .gitlab/ci/frontend.gitlab-ci.yml.
6. These jobs can also be forced to run in merge requests whose title include UPDATE CACHE (this can be useful to warm the caches in a MR that updates the cache keys).

Artifacts strategy

We limit the artifacts that are saved and retrieved by jobs to the minimum in order to reduce the upload/download time and costs, as well as the artifacts storage.

Pre-clone step

The gitlab-org/gitlab project on GitLab.com uses a pre-clone step to seed the project with a recent archive of the repository. This is done for several reasons:

• It speeds up builds because a 800 MB download only takes seconds, as opposed to a full Git clone.
• It significantly reduces load on the file server, as smaller deltas mean less time spent in git pack-objects.

The pre-clone step works by using the CI_PRE_CLONE_SCRIPT variable defined by GitLab.com shared runners.

The CI_PRE_CLONE_SCRIPT is currently defined as a project CI/CD variable:

(
  echo "Downloading archived master..."
  wget -O /tmp/gitlab.tar.gz https://storage.googleapis.com/gitlab-ci-git-repo-cache/project-278964/gitlab-master-shallow.tar.gz

  if [ ! -f /tmp/gitlab.tar.gz ]; then
      echo "Repository cache not available, cloning a new directory..."
      exit
  fi

  rm -rf $CI_PROJECT_DIR
  echo "Extracting tarball into $CI_PROJECT_DIR..."
  mkdir -p $CI_PROJECT_DIR
  cd $CI_PROJECT_DIR
  tar xzf /tmp/gitlab.tar.gz
  rm -f /tmp/gitlab.tar.gz
  chmod a+w $CI_PROJECT_DIR
)

The first step of the script downloads gitlab-master.tar.gz from Google Cloud Storage. There is a GitLab CI job named cache-repo that is responsible for keeping that archive up-to-date. Every two hours on a scheduled pipeline, it does the following:

1. Creates a fresh clone of the gitlab-org/gitlab repository on GitLab.com.
2. Saves the data as a .tar.gz.
3. Uploads it into the Google Cloud Storage bucket.

When a CI job runs with this configuration, the output looks something like this:

$ eval "$CI_PRE_CLONE_SCRIPT"
Downloading archived master...
Extracting tarball into /builds/group/project...
Fetching changes...
Reinitialized existing Git repository in /builds/group/project/.git/

Note that the Reinitialized existing Git repository message shows that the pre-clone step worked. The runner runs git init, which overwrites the Git configuration with the appropriate settings to fetch from the GitLab repository.

CI_REPO_CACHE_CREDENTIALS contains the Google Cloud service account JSON for uploading to the gitlab-ci-git-repo-cache bucket. (If you’re a GitLab Team Member, find credentials in the GitLab shared 1Password account.

Note that this bucket should be located in the same continent as the runner, or you can incur network egress charges.

CI configuration internals

Stages

The current stages are:

• sync: This stage is used to synchronize changes from gitlab-org/gitlab to gitlab-org/gitlab-foss.
• prepare: This stage includes jobs that prepare artifacts that are needed by jobs in subsequent stages.
• build-images: This stage includes jobs that prepare Docker images that are needed by jobs in subsequent stages or downstream pipelines.
• fixtures: This stage includes jobs that prepare fixtures needed by frontend tests.
• test: This stage includes most of the tests, DB/migration jobs, and static analysis jobs.
• post-test: This stage includes jobs that build reports or gather data from the test stage’s jobs (e.g. coverage, Knapsack metadata etc.).
• review-prepare: This stage includes a job that build the CNG images that are later used by the (Helm) Review App deployment (see Review Apps for details).
• review: This stage includes jobs that deploy the GitLab and Docs Review Apps.
• dast: This stage includes jobs that run a DAST full scan against the Review App that is deployed in stage review.
• qa: This stage includes jobs that perform QA tasks against the Review App that is deployed in stage review.
• post-qa: This stage includes jobs that build reports or gather data from the qa stage’s jobs (e.g. Review App performance report).
• pages: This stage includes a job that deploys the various reports as GitLab Pages (e.g. coverage-ruby, coverage-javascript, and webpack-report (found at https://gitlab-org.gitlab.io/gitlab/webpack-report/, but there is an issue with the deployment).
• notify: This stage includes jobs that notify various failures to Slack.

Default image

The default image is defined in .gitlab-ci.yml.

It includes Ruby, Go, Git, Git LFS, Chrome, Node, Yarn, PostgreSQL, and Graphics Magick.

The images used in our pipelines are configured in the gitlab-org/gitlab-build-images project, which is push-mirrored to gitlab/gitlab-build-images for redundancy.

The current version of the build images can be found in the “Used by GitLab section”.

Dependency Proxy

Some of the jobs are using images from Docker Hub, where we also use ${GITLAB_DEPENDENCY_PROXY} as a prefix to the image path, so that we pull images from our Dependency Proxy.

${GITLAB_DEPENDENCY_PROXY} is a group CI/CD variable defined in gitlab-org as ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/. This means when we use an image defined as:

image: ${GITLAB_DEPENDENCY_PROXY}alpine:edge

Projects in the gitlab-org group pull from the Dependency Proxy, while forks that reside on any other personal namespaces or groups fall back to Docker Hub unless ${GITLAB_DEPENDENCY_PROXY} is also defined there.

Default variables

In addition to the predefined CI/CD variables, each pipeline includes default variables defined in .gitlab-ci.yml.

Common job definitions

Most of the jobs extend from a few CI definitions defined in .gitlab/ci/global.gitlab-ci.yml that are scoped to a single configuration keyword.

rules, if: conditions and changes: patterns

We’re using the rules keyword extensively.

All rules definitions are defined in rules.gitlab-ci.yml, then included in individual jobs via extends.

The rules definitions are composed of if: conditions and changes: patterns, which are also defined in rules.gitlab-ci.yml and included in rules definitions via YAML anchors

if: conditions

changes: patterns

Return to Development documentation