diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-06 03:08:15 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-06 03:08:15 +0300 |
commit | 6c36d81714a3ae8ca82186451fffab8bc635ac99 (patch) | |
tree | 8c3977b4ac6aa1ab321b598a080456762294ea22 /doc/ci/pipelines | |
parent | 353c244f5c32ad3283e9ab6ff4b599f96a010b76 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/ci/pipelines')
-rw-r--r-- | doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png | bin | 42573 -> 83953 bytes | |||
-rw-r--r-- | doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png | bin | 37749 -> 81552 bytes | |||
-rw-r--r-- | doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png | bin | 36039 -> 77811 bytes | |||
-rw-r--r-- | doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png | bin | 25969 -> 63697 bytes | |||
-rw-r--r-- | doc/ci/pipelines/settings.md | 231 |
5 files changed, 111 insertions, 120 deletions
diff --git a/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png Binary files differindex e73845b39b0..ff6b3af0a28 100644 --- a/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png +++ b/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png diff --git a/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png Binary files differindex 1ce77881bc4..b0923ab96d9 100644 --- a/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png +++ b/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png diff --git a/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png Binary files differindex 41840108441..ae7cdc5b43e 100644 --- a/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png +++ b/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png diff --git a/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png Binary files differindex d7d8f3c63d2..b3b98313350 100644 --- a/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png +++ b/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md index 683939ac81a..21416d003ea 100644 --- a/doc/ci/pipelines/settings.md +++ b/doc/ci/pipelines/settings.md @@ -6,72 +6,91 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.h type: reference, howto --- -# Pipeline settings **(FREE)** +# Customize pipeline configuration **(FREE)** -To reach the pipelines settings navigate to your project's -**Settings > CI/CD**. - -The following settings can be configured per project. +You can customize how pipelines run for your project. <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> -For an overview, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s). +For an overview of pipelines, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s). Watch also [GitLab CI pipeline tutorial for beginners](https://www.youtube.com/watch?v=Jav4vbUrqII). -You can use the pipeline status to determine if a merge request can be merged: +## Visibility of pipelines -- [Merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md). -- [Only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds). +Pipeline visibility is determined by: -## Git strategy +- Your current [user access level](../../user/permissions.md). +- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**. -With Git strategy, you can choose the default way your repository is fetched -from GitLab in a job. +NOTE: +If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting). -There are two options. Using: +This also determines the visibility of these related features: -- `git clone`, which is slower because it clones the repository from scratch - for every job, ensuring that the local working copy is always pristine. -- `git fetch`, which is default in GitLab and faster as it re-uses the local working copy (falling - back to clone if it doesn't exist). - This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy). +- Job output logs +- Job artifacts +- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)** -The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy) -in `.gitlab-ci.yml`. +Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649). -## Git shallow clone +If **Public pipelines** is enabled (default): -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28919) in GitLab 12.0. +- For **public** projects, anyone can view the pipelines and related features. +- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines + and related features. +- For **private** projects, any project member (Guest or higher) can view the pipelines + and related features. -It is possible to limit the number of changes that GitLab CI/CD fetches when cloning -a repository. Setting a limit to `git depth` can speed up Pipelines execution. +If **Public pipelines** is disabled: -In GitLab 12.0 and later, newly created projects automatically have a default -`git depth` value of `50`. The maximum allowed value is `1000`. +- For **public** projects, anyone can view the pipelines, but only members + (Reporter or higher) can access the related features. +- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines. + However, only members (reporter or higher) can access the job related features. +- For **private** projects, only project members (reporter or higher) + can view the pipelines or access the related features. -To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time, -keep the value empty or set to `0`. +## Auto-cancel redundant pipelines -This value can also be [overridden by `GIT_DEPTH`](../large_repositories/index.md#shallow-cloning) variable in `.gitlab-ci.yml` file. +You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings: -## Timeout +1. Go to **Settings > CI/CD**. +1. Expand **General Pipelines**. +1. Check the **Auto-cancel redundant pipelines** checkbox. +1. Click **Save changes**. -Timeout defines the maximum amount of time in minutes that a job is able run. -This is configurable under your project's **Settings > CI/CD > General pipelines settings**. -The default value is 60 minutes. Decrease the time limit if you want to impose -a hard limit on your jobs' running time or increase it otherwise. In any case, -if the job surpasses the threshold, it is marked as failed. +Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a +running job can be cancelled before it completes. -### Timeout overriding for runners +## Skip outdated deployment jobs -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9. -Project defined timeout (either specific timeout set by user or the default -60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner). +Your project may have multiple concurrent deployment jobs that are +scheduled to run in the same time frame. -## Maximum artifacts size **(FREE SELF)** +This can lead to a situation where an older deployment job runs after a +newer one, which may not be what you want. -For information about setting a maximum artifact size for a project, see -[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size). +To avoid this scenario: + +1. Go to **Settings > CI/CD**. +1. Expand **General pipelines**. +1. Check the **Skip outdated deployment jobs** checkbox. +1. Click **Save changes**. + +When enabled, any older deployments job are skipped when a new deployment starts. + +For more information, see [Deployment safety](../environments/deployment_safety.md). + +## Retry outdated jobs + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6. + +A deployment job can fail because a newer one has run. If you retry the failed deployment job, the +environment could be overwritten with older source code. If you click **Retry**, a modal warns you +about this and asks for confirmation. + +For more information, see [Deployment safety](../environments/deployment_safety.md). ## Custom CI/CD configuration file @@ -115,6 +134,52 @@ configuration file. For example: Other users and projects can access the configuration file without being able to edit it. +## Git strategy + +With Git strategy, you can choose the default way your repository is fetched +from GitLab in a job. + +There are two options. Using: + +- `git clone`, which is slower because it clones the repository from scratch + for every job, ensuring that the local working copy is always pristine. +- `git fetch`, which is default in GitLab and faster as it re-uses the local working copy (falling + back to clone if it doesn't exist). + This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy). + +The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy) +in `.gitlab-ci.yml`. + +## Git shallow clone + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28919) in GitLab 12.0. + +It is possible to limit the number of changes that GitLab CI/CD fetches when cloning +a repository. Setting a limit to `git depth` can speed up Pipelines execution. + +In GitLab 12.0 and later, newly created projects automatically have a default +`git depth` value of `50`. The maximum allowed value is `1000`. + +To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time, +keep the value empty or set to `0`. + +This value can also be [overridden by `GIT_DEPTH`](../large_repositories/index.md#shallow-cloning) variable in `.gitlab-ci.yml` file. + +## Timeout + +Timeout defines the maximum amount of time in minutes that a job is able run. +This is configurable under your project's **Settings > CI/CD > General pipelines settings**. +The default value is 60 minutes. Decrease the time limit if you want to impose +a hard limit on your jobs' running time or increase it otherwise. In any case, +if the job surpasses the threshold, it is marked as failed. + +### Timeout overriding for runners + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7. + +Project defined timeout (either specific timeout set by user or the default +60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner). + ## Test coverage parsing If you use test coverage in your code, GitLab can capture its output in the @@ -184,84 +249,6 @@ For example: lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g' ``` -## Visibility of pipelines - -Pipeline visibility is determined by: - -- Your current [user access level](../../user/permissions.md). -- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**. - -NOTE: -If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting). - -This also determines the visibility of these related features: - -- Job output logs -- Job artifacts -- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)** - -Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649). - -If **Public pipelines** is enabled (default): - -- For **public** projects, anyone can view the pipelines and related features. -- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines - and related features. -- For **private** projects, any project member (guest or higher) can view the pipelines - and related features. - -If **Public pipelines** is disabled: - -- For **public** projects, anyone can view the pipelines, but only members - (reporter or higher) can access the related features. -- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines. - However, only members (reporter or higher) can access the job related features. -- For **private** projects, only project members (reporter or higher) - can view the pipelines or access the related features. - -## Auto-cancel redundant pipelines - -You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings: - -1. Go to **Settings > CI/CD**. -1. Expand **General Pipelines**. -1. Check the **Auto-cancel redundant pipelines** checkbox. -1. Click **Save changes**. - -Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a -running job can be cancelled before it completes. - -## Skip outdated deployment jobs - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9. - -Your project may have multiple concurrent deployment jobs that are -scheduled to run in the same time frame. - -This can lead to a situation where an older deployment job runs after a -newer one, which may not be what you want. - -To avoid this scenario: - -1. Go to **Settings > CI/CD**. -1. Expand **General pipelines**. -1. Check the **Skip outdated deployment jobs** checkbox. -1. Click **Save changes**. - -When enabled, any older deployments job are skipped when a new deployment starts. - -For more information, see [Deployment safety](../environments/deployment_safety.md). - -## Retry outdated jobs - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6. - -A deployment job can fail because a newer one has run. If you retry the failed deployment job, the -environment could be overwritten with older source code. If you click **Retry**, a modal warns you -about this and asks for confirmation. - -For more information, see [Deployment safety](../environments/deployment_safety.md). - ## Pipeline Badges In the pipelines settings page you can find pipeline status and test coverage @@ -353,6 +340,10 @@ https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text ![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130) +## Related topics + +- [Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size). + <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues |