Skip to content
Snippets Groups Projects
Verified Commit 3d7e8f75 authored by Rémy Coutable's avatar Rémy Coutable
Browse files

Add documentation for the GitLab pipelines configuration


Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
parent 1da84266
No related branches found
No related tags found
2 merge requests!17226WIP: Step 2: Support multiple indices to Elasticsearch Admin options,!16528Add documentation for the GitLab pipelines configuration
Pipeline #82620350 passed
Pipeline: GitLab Docs DEPRECATED

#82621223

    # 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
    ......@@ -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)
    ......
    ......@@ -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)
    ......
    # 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)
    ......@@ -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
    ......
    ......@@ -21,7 +21,6 @@ class GitlabDanger
    single_codebase
    gitlab_ui_wg
    ce_ee_vue_templates
    only_documentation
    ].freeze
    MESSAGE_PREFIX = '==>'.freeze
    ......
    0% Loading or .
    You are about to add 0 people to the discussion. Proceed with caution.
    Finish editing this message first!
    Please register or to comment