Skip to content

G
gitlab-ce
Commit 560f42f5 authored by Marcel Amirault's avatar Marcel Amirault
Browse files
Options

Merge branch 'selhorn-pipeline-status' into 'master' 

Reordered docs to match UI

See merge request gitlab-org/gitlab!65485
parents 237d9c71 3d5efc6c
Show whitespace changes
Inline Side-by-side
Showing with 111 additions and 120 deletions
doc/ci/pipelines/settings.md
View file @ 560f42f5
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7