Merge branch 'docs-gitlab-pipelines' into 'master'

Add documentation for the GitLab pipelines configuration

See merge request gitlab-org/gitlab!16528

danger/only_documentation/Dangerfile

-# rubocop:disable Style/SignalException
-# frozen_string_literal: true
-
-has_only_docs_changes = helper.all_changed_files.all? { |file| file.start_with?('doc/', '.gitlab/ci/docs.gitlab-ci.yml', '.markdownlint.json') || file.end_with?('.md') }
-is_docs_only_branch = gitlab.branch_for_head =~ /(^docs[\/-].*|.*-docs$)/
-
-if is_docs_only_branch && !has_only_docs_changes
-  fail "It seems like your branch name has a `docs` prefix or suffix. "\
-    "The CI won't run the full pipeline, but you also have changed non-docs files. "\
-    "Please recreate this MR with a new branch name."
-end
-
-if has_only_docs_changes && !is_docs_only_branch
-  markdown(<<~MARKDOWN)
-
-  ## Documentation only changes
-
-  Hey! Seems your merge request contains only docs changes.
-  Tired of waiting 2 hours for the pipeline to finish?
-  Next time, prepend `docs-` to [your branch name](https://docs.gitlab.com/ee/development/documentation/#branch-naming)
-  and the pipeline will finish before you say GitLab (x300)!
-
-  MARKDOWN
-end

doc/development/README.md

@@ -18,6 +18,7 @@ description: 'Learn how to contribute to GitLab.'
 - [Generate a changelog entry with `bin/changelog`](changelog.md)
 - [Code review guidelines](code_review.md) for reviewing code and having code reviewed
 - [Database review guidelines](database_review.md) for reviewing database-related changes and complex SQL queries
+- [Pipelines for the GitLab project](pipelines.md)
 - [Automatic CE->EE merge](automatic_ce_ee_merge.md)
 - [Guidelines for implementing Enterprise Edition features](ee_features.md)
 - [Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)

doc/development/documentation/index.md

@@ -152,20 +152,6 @@ disqus_identifier: 'https://docs.gitlab.com/my-old-location/README.html'
 Note: it is necessary to include the file name in the `disqus_identifier` URL,
 even if it's `index.html` or `README.html`.
 
-## Branch naming
-
-If your contribution contains **only** documentation changes, you can speed up
-the CI process by following these branch naming conventions:
-
-| Branch name           | Valid example                |
-|:----------------------|:-----------------------------|
-| Starting with `docs/` | `docs/update-api-issues`     |
-| Starting with `docs-` | `docs-update-api-issues`     |
-| Ending in `-docs`     | `123-update-api-issues-docs` |
-
-If your branch name matches any of the above, it will run only the docs
-tests. If not, the whole application test suite will run (including docs tests).
-
 ## Merge requests for GitLab documentation
 
 Before getting started, make sure you read the introductory section
@@ -173,7 +159,6 @@ Before getting started, make sure you read the introductory section
 [documentation workflow](workflow.md).
 
 - Use the current [merge request description template](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/merge_request_templates/Documentation.md)
-- Use the correct [branch name](#branch-naming)
 - Label the MR `Documentation`
 - Assign the correct milestone (see note below)
 
@@ -283,10 +268,6 @@ Several [rspec tests](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/feat
 are run to ensure GitLab documentation renders and works correctly. In particular, that [main docs landing page](../../README.md) will work correctly from `/help`.
 For example, [GitLab.com's `/help`](https://gitlab.com/help).
 
-CAUTION: **Caution:**
-Because the rspec tests only run in a full pipeline, and not a special [docs-only pipeline](#branch-naming), it is possible
-to merge changes that will break `master` from a merge request with a successful docs-only pipeline run.
-
 ## Docs site architecture
 
 See the [Docs site architecture](site_architecture/index.md) page to learn
@@ -309,14 +290,9 @@ The live preview is currently enabled for the following projects:
 - <https://gitlab.com/gitlab-org/gitlab>
 - <https://gitlab.com/gitlab-org/gitlab-runner>
 
-If your branch contains only documentation changes, you can use
-[special branch names](#branch-naming) to avoid long-running pipelines.
-
-For [docs-only changes](#branch-naming), the review app is run automatically.
-For all other branches, you can use the manual `review-docs-deploy-manual` job
-in your merge request. You will need at least Maintainer permissions to be able
-to run it. In the mini pipeline graph, you should see a `>>` icon. Clicking it will
-reveal the `review-docs-deploy-manual` job. Click the play button to start the job.
+If your merge request has docs changes, you can use the manual `review-docs-deploy` job
+to deploy the docs review app for your merge request.
+You will need at least Maintainer permissions to be able to run it.
 
 ![Manual trigger a docs build](img/manual_build_docs.png)
 

doc/development/pipelines.md

+# 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`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml)
+which itself includes files under
+[`.gitlab/ci/`](https://gitlab.com/gitlab-org/gitlab/tree/master/.gitlab/ci)
+for easier maintenance.
+
+We're striving to [dogfood](https://about.gitlab.com/handbook/engineering/#dogfooding)
+GitLab [CI/CD features and best-practices](../ci/yaml/README.md)
+as much as possible.
+
+## Stages
+
+The current stages are:
+
+- `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-`, `geo/`, or ends with `-geo`).
+- `test`: This stage includes most of the tests, DB/migration jobs, and static analysis jobs.
+- `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](testing_guide/review_apps.md) 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-test`: This stage includes jobs that build reports or gather data from
+  the previous stages' jobs (e.g. coverage, Knapsack metadata etc.).
+- `pages`: This stage includes a job that deploys the various reports as
+  GitLab pages (e.g. <https://gitlab-org.gitlab.io/gitlab/coverage-ruby/>,
+  <https://gitlab-org.gitlab.io/gitlab/coverage-javascript/>,
+  <https://gitlab-org.gitlab.io/gitlab/webpack-report/>).
+
+## Default image
+
+The default image is currently
+`dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.6.3-golang-1.11-git-2.22-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.33`.
+It includes Ruby 2.6.3, Go 1.11, Git 2.22, Chrome 73, Node 12, Yarn 1.16,
+PostgreSQL 9.6, and Graphics Magick 1.3.33.
+
+The images used in our pipelines are configured in the
+[`gitlab-org/gitlab-build-images`](https://gitlab.com/gitlab-org/gitlab-build-images)
+project, which is push-mirrored to <https://dev.gitlab.org/gitlab/gitlab-build-images>
+for redundancy.
+
+The current version of the build images can be found in the
+["Used by GitLab CE/EE section"](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/.gitlab-ci.yml).
+
+## Default variables
+
+In addition to the [predefined variables](../ci/variables/predefined_variables.md),
+each pipeline includes the following [variables](../ci/variables/README.md):
+
+- `RAILS_ENV: "test"`
+- `NODE_ENV: "test"`
+- `SIMPLECOV: "true"`
+- `GIT_DEPTH: "20"`
+- `GIT_SUBMODULE_STRATEGY: "none"`
+- `GET_SOURCES_ATTEMPTS: "3"`
+- `KNAPSACK_RSPEC_SUITE_REPORT_PATH: knapsack/${CI_PROJECT_NAME}/rspec_report-master.json`
+- `EE_KNAPSACK_RSPEC_SUITE_REPORT_PATH: knapsack/${CI_PROJECT_NAME}/rspec_report-master-ee.json`
+- `FLAKY_RSPEC_SUITE_REPORT_PATH: rspec_flaky/report-suite.json`
+- `BUILD_ASSETS_IMAGE: "false"`
+- `ES_JAVA_OPTS: "-Xms256m -Xmx256m"`
+- `ELASTIC_URL: "http://elastic:changeme@docker.elastic.co-elasticsearch-elasticsearch:9200"`
+
+## Common job definitions
+
+Most of the jobs [extend from a few CI definitions](../ci/yaml/README.md#extends)
+that are scoped to a single
+[configuration parameter](../ci/yaml/README.md#configuration-parameters).
+
+These common definitions are:
+
+- `.default-tags`: Ensures a job has the `gitlab-org` tag to ensure it's using
+  our dedicated runners.
+- `.default-retry`: Allows a job to retry upon `unknown_failure`, `api_failure`,
+  `runner_system_failure`.
+- `.default-before_script`: Allows a job to use a default `before_script` definition
+  suitable for Ruby/Rails tasks that may need a database running (e.g. tests).
+- `.default-cache`: Allows a job to use a default `cache` definition suitable for
+  Ruby/Rails and frontend tasks.
+- `.default-only`: Restricts the cases where a job is created. This currently
+  includes `master`, `/^[\d-]+-stable(-ee)?$/` (stable branches),
+  `/^\d+-\d+-auto-deploy-\d+$/` (security branches), `merge_requests`, `tags`.
+  Note that jobs won't be created for branches with this default configuration.
+- `.only-review`: Only creates a job for the `gitlab-org` namespace and if
+  Kubernetes integration is available. Also, prevents a job from being created
+  for `master` and auto-deploy branches.
+- `.only-review-schedules`: Same as `.only-review` but also restrict a job to
+  only run for [schedules](../user/project/pipelines/schedules.md).
+- `.use-pg`: Allows a job to use the `postgres:9.6.14` and `redis:alpine` services.
+- `.use-pg-10`: Allows a job to use the `postgres:10.9` and `redis:alpine` services.
+- `.only-ee`: Only creates a job for the `gitlab` project.
+
+## Changes detection
+
+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](../ci/yaml/README.md#onlychangesexceptchanges)
+from a commit or MR by extending from the following CI definitions:
+
+- `.only-code-changes`: Allows a job to only be created upon code-related changes.
+- `.only-qa-changes`: Allows a job to only be created upon QA-related changes.
+- `.only-docs-changes`: Allows a job to only be created upon docs-related changes.
+- `.only-code-qa-changes`: Allows a job to only be created upon code-related 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.**
+
+## Directed acyclic graph
+
+We're using the [`needs:`](../ci/yaml/README.md#needs) keyword to
+execute jobs out of order for the following jobs:
+
+```mermaid
+graph RL;
+  A[setup-test-env];
+  B["gitlab:assets:compile<br/>(master only)"];
+  C[gitlab:assets:compile pull-cache];
+  D["cache gems<br/>(master and tags only)"];
+  E[review-build-cng];
+  F[build-qa-image];
+  G[review-deploy];
+  G2["schedule:review-deploy<br/>(master only)"];
+  H[karma];
+  I[jest];
+  J["compile-assets<br/>(master only)"];
+  K[compile-assets pull-cache];
+  L[webpack-dev-server];
+  M[coverage];
+  N[pages];
+  O[static-analysis];
+  P["package-and-qa-manual:master<br/>(master schedule only)"];
+  Q[package-and-qa];
+  R[package-and-qa-manual];
+
+subgraph "`prepare` stage"
+    A
+    F
+    J
+    K
+    end
+
+subgraph "`test` stage"
+    B --> |needs| A;
+    C --> |needs| A;
+    D --> |needs| A;
+    H -.-> |depends on| A;
+    H -.-> |depends on| J;
+    H -.-> |depends on| K;
+    I -.-> |depends on| A;
+    I -.-> |depends on| J;
+    I -.-> |depends on| K;
+    L -.-> |depends on| A;
+    L -.-> |depends on| J;
+    L -.-> |depends on| K;
+    downtime_check --> |needs and depends on| A;
+    db:* --> |needs| A;
+    gitlab:setup --> |needs| A;
+    O -.-> |depends on| A;
+    O -.-> |depends on| B;
+    O -.-> |depends on| C;
+    downtime_check --> |needs and depends on| A;
+    end
+
+subgraph "`review-prepare` stage"
+    E --> |needs| C;
+    X["schedule:review-build-cng<br/>(master schedule only)"] --> |needs| B;
+    end
+
+subgraph "`review` stage"
+    G --> |needs| E;
+    G2 --> |needs| E;
+    end
+
+subgraph "`qa` stage"
+    Q --> |needs| C;
+    Q --> |needs| F;
+    R --> |needs| C;
+    R --> |needs| F;
+    P --> |needs| B;
+    P --> |needs| F;
+    review-qa-smoke -.-> |depends on| G;
+    review-qa-all -.-> |depends on| G;
+    review-qa-performance -.-> |depends on| G;
+    X2["schedule:review-performance<br/>(master only)"] -.-> |depends on| G2;
+    dast -.-> |depends on| G;
+    end
+
+subgraph "`post-test` stage"
+    M
+    end
+
+subgraph "`pages` stage"
+    N -.-> |depends on| B;
+    N -.-> |depends on| H;
+    N -.-> |depends on| M;
+    end
+```
+
+## Test jobs
+
+Consult [GitLab tests in the Continuous Integration (CI) context](testing_guide/ci.md)
+for more information.
+
+## Review app jobs
+
+Consult the [Review Apps](testing_guide/review_apps.md) dedicated page for more information.
+
+---
+
+[Return to Development documentation](README.md)

doc/development/testing_guide/end_to_end/index.md

@@ -7,24 +7,6 @@ as expected across the entire software stack and architecture, including
 integration of all micro-services and components that are supposed to work
 together.
 
-## Branch naming
-
-If your contribution contains **only** changes under the
-[`qa/` folder](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa), you can
-speed up the CI process by following some branch naming conventions. You have
-three choices:
-
-| Branch name           | Valid example                |
-|:----------------------|:-----------------------------|
-| Starting with `qa/`   | `qa/new-oauth-login-test`     |
-| Starting with `qa-`   | `qa-new-oauth-login-test`     |
-| Ending in `-qa`       | `123-new-oauth-login-test-qa` |
-
-If your branch name matches any of the above, it will run only the QA-related
-jobs.
-If it does not, the whole application test suite will run (including QA-related
-jobs).
-
 ## How do we test GitLab?
 
 We use [Omnibus GitLab][omnibus-gitlab] to build GitLab packages and then we

lib/gitlab_danger.rb

@@ -21,7 +21,6 @@ class GitlabDanger
     single_codebase
     gitlab_ui_wg
     ce_ee_vue_templates
-    only_documentation
   ].freeze
 
   MESSAGE_PREFIX = '==>'.freeze