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
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
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1984) in GitLab 9.3.
> - Made [available in all tiers](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) in 13.2.
Ensuring your project's code stays simple, readable and easy to contribute to can be problematic. With the help of [GitLab CI/CD](../../../ci/index.md), you can analyze your
source code quality using GitLab Code Quality.
To ensure your project's code stays simple, readable, and easy to contribute to,
you can use [GitLab CI/CD](../../../ci/index.md) to analyze your source code quality.
For example, while you're implementing a feature, you can run Code Quality reports
to analyze how your improvements are impacting your code's quality. You can
use this information to ensure that your changes are improving performance rather
than degrading it.
Code Quality:
- Uses [Engines](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
- Uses [plugins](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
free and open source. Code Quality does not require a Code Climate
subscription.
- Runs in [pipelines](../../../ci/pipelines/index.md) using a Docker image built in the
- Can make use of a [template](#example-configuration).
- Is available by using [Auto Code Quality](../../../topics/autodevops/stages.md#auto-code-quality), provided by [Auto DevOps](../../../topics/autodevops/index.md).
- Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
