- Default image
- Default variables
- Common job definitions
- Changes detection
- Rules conditions and changes patterns
- Directed acyclic graph
- Test jobs
- Review app jobs
Pipelines for https://gitlab.com/gitlab-org/gitlab and https://gitlab.com/gitlab-org/gitlab-foss (as well as the
dev instance’s mirrors) are configured in the usual
which itself includes files under
for easier maintenance.
The current stages are:
sync: This stage is used to synchronize changes from https://gitlab.com/gitlab-org/gitlab to https://gitlab.com/gitlab-org/gitlab-foss.
prepare: This stage includes jobs that prepare artifacts that are needed by jobs in subsequent stages.
quick-test: This stage includes test jobs that should run first and fail the pipeline early (currently used to run Geo tests when the branch name starts with
geo/, or ends with
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
teststage’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.
qa: This stage includes jobs that perform QA tasks against the Review App that is deployed in the previous stage.
post-qa: This stage includes jobs that build reports or gather data from the
qastage’s jobs (e.g. Review App performance report).
notification: This stage includes jobs that sends notifications about pipeline status.
The default image is currently
It includes Ruby 2.6.5, Go 1.12, Git 2.24, Git LFS 2.9, Chrome 73, Node 12, Yarn 1.16, PostgreSQL 9.6, and Graphics Magick 1.3.33.
The current version of the build images can be found in the “Used by GitLab section”.
In addition to the predefined variables, each pipeline includes default variables defined in https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml.
These common definitions are:
.default-tags: Ensures a job has the
gitlab-orgtag to ensure it’s using our dedicated runners.
.default-retry: Allows a job to retry upon
.default-before_script: Allows a job to use a default
before_scriptdefinition suitable for Ruby/Rails tasks that may need a database running (e.g. tests).
.default-cache: Allows a job to use a default
cachedefinition suitable for Ruby/Rails and frontend tasks.
.default-only: Restricts the cases where a job is created. This currently includes
tags. Note that jobs won’t be created for branches with this default configuration.
.only:variables-canonical-dot-com: Only creates a job if the project is located under https://gitlab.com/gitlab-org.
.only:variables_refs-canonical-dot-com-schedules: Same as
.only:variables-canonical-dot-combut add the condition that pipeline is scheduled.
.except:refs-deploy: Don’t create a job if the
refis an auto-deploy branch.
.except:refs-master-tags-stable-deploy: Don’t create a job if the
refis one of:
- a tag
- a stable branch
- an auto-deploy branch
.only:kubernetes: Only creates a job if a Kubernetes integration is enabled on the project.
.only-review: This extends from:
.only-review-schedules: This extends from:
.use-pg9: Allows a job to use the
.use-pg10: Allows a job to use the
.use-pg9-ee: Same as
.use-pg9but also use the
.use-pg10-ee: Same as
.use-pg10but also use the
.only-ee: Only creates a job for the
.only-ee-as-if-foss: Same as
.only-eebut simulate the FOSS project by setting the
If a job extends from
.default-only (and most of the jobs should), it can restrict
the cases where it should be created
based on the changes
from a commit or MR by extending from the following CI definitions:
.only:changes-code: Allows a job to only be created upon code-related changes.
.only:changes-qa: Allows a job to only be created upon QA-related changes.
.only:changes-docs: Allows a job to only be created upon docs-related changes.
.only:changes-graphql: Allows a job to only be created upon GraphQL-related changes.
.only:changes-code-backstage: Allows a job to only be created upon code-related or backstage-related (e.g. Danger, RuboCop, specs) changes.
.only:changes-code-qa: Allows a job to only be created upon code-related or QA-related changes.
.only:changes-code-backstage-qa: Allows a job to only be created upon code-related, backstage-related (e.g. Danger, RuboCop, specs) or QA-related changes.
See https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/global.gitlab-ci.yml for the list of exact patterns.
We’re making use of the
rules keyword but we’re currently
if conditions and
changes patterns lists since they cannot be shared across
included files as we do with
If you update an
if condition or
patterns list, make sure to mass-update those across all the CI config files (i.e.
This condition limits jobs creation to commits under the
gitlab-org/ top-level group
on GitLab.com only. This is similar to the
.only:variables-canonical-dot-com CI definition:
.if-canonical-gitlab: &if-canonical-gitlab if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/'
Same as the “Canonical commits only” condition above but further limits jobs creation
to merge requests only (i.e. this won’t run for
master, stable or auto-deploy branches).
This is similar to the
.if-canonical-gitlab-merge-request: &if-canonical-gitlab-merge-request if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_MERGE_REQUEST_IID'
Similar patterns as for
.code-patterns: &code-patterns - ...
Similar patterns as for
.qa-patterns: &qa-patterns - ...
Similar patterns as for
.code-qa-patterns: &code-qa-patterns - ...
We’re using the
needs: keyword to
execute jobs out of order for the following jobs:
(master only)"]; C[gitlab:assets:compile pull-cache]; D["cache gems
(master and tags only)"]; E[review-build-cng]; F[build-qa-image]; G[review-deploy]; G2["schedule:review-deploy
(master only)"]; H[karma]; I[jest]; J["compile-assets pull-push-cache
(master only)"]; K[compile-assets pull-cache]; L[webpack-dev-server]; M[coverage]; N[pages]; O[static-analysis]; Q[package-and-qa]; S["RSpec
(e.g. rspec unit pg9)"] T[retrieve-tests-metadata]; subgraph "`prepare` stage" A B C F K J T end subgraph "`test` stage" D --> |needs| A; H -.-> |needs and depends on| A; H -.-> |needs and depends on| K; I -.-> |needs and depends on| A; I -.-> |needs and depends on| K; L -.-> |needs and depends on| A; L -.-> |needs and depends on| K; O -.-> |needs and depends on| A; O -.-> |needs and depends on| K; S -.-> |needs and depends on| A; S -.-> |needs and depends on| K; S -.-> |needs and depends on| T; downtime_check --> |needs and depends on| A; db:* --> |needs| A; gitlab:setup --> |needs| A; downtime_check --> |needs and depends on| A; graphql-docs-verify --> |needs| A; end subgraph "`review-prepare` stage" E --> |needs| C; X["schedule:review-build-cng
(master schedule only)"] --> |needs| C; end subgraph "`review` stage" G G2 end subgraph "`qa` stage" Q --> |needs| C; Q --> |needs| F; review-qa-smoke -.-> |needs and depends on| G; review-qa-all -.-> |needs and depends on| G; review-performance -.-> |needs and depends on| G; X2["schedule:review-performance
(master only)"] -.-> |needs and depends on| G2; dast -.-> |needs and depends on| G; end subgraph "`post-test` stage" M end subgraph "`pages` stage" N -.-> |depends on| C; N -.-> |depends on| H; N -.-> |depends on| M; end
Consult GitLab tests in the Continuous Integration (CI) context for more information.
Consult the Review Apps dedicated page for more information.