=html_escape(_("The name of the CI/CD configuration file. A path relative to the root directory is optional (for example %{code_open}my/path/.myfile.yml%{code_close})."))%{code_open: '<code>'.html_safe,code_close: '</code>'.html_safe}
=html_escape(_('The number of changes to fetch from GitLab when cloning a repository. Lower values can speed up pipeline execution. Set to %{code_open}0%{code_close} or blank to fetch all branches and tags for each job'))%{code_open: '<code>'.html_safe,code_close: '</code>'.html_safe}
|**[Audit events](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives administrators the ability to view any modifications made within the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. | Premium+ | **{check-circle}** Yes | Instance, Group, Project |
|**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance. | Premium+ | **{dotted-circle}** No | Instance |
|**[Credentials inventory](../user/admin_area/credentials_inventory.md)**<br>With a credentials inventory, GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance. | Ultimate | **{dotted-circle}** No | Instance |
|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#require-code-owner-approval-on-a-protected-branch) and [custom CI Configuration Paths](../ci/pipelines/settings.md#custom-cicd-configuration-file)**<br> GitLab Premium users can leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles. | Premium+ | **{check-circle}** Yes | Project |
|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#require-code-owner-approval-on-a-protected-branch) and [custom CI Configuration Paths](../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file)**<br> GitLab Premium users can leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles. | Premium+ | **{check-circle}** Yes | Project |
|**[Compliance frameworks](../user/project/settings/index.md#compliance-frameworks)**<br>Create a custom compliance framework at the group level to describe the type of compliance requirements any child project needs to follow. | Premium+ | **{check-circle}** Yes | Group |
|**[Compliance pipelines](../user/project/settings/index.md#compliance-pipeline-configuration)**<br>Define a pipeline configuration to run for any projects with a given compliance framework. | Ultimate | **{check-circle}** Yes | Group |
|**[Compliance dashboard](../user/compliance/compliance_dashboard/index.md)**<br>Quickly get visibility into the compliance posture of your organization. | Ultimate | **{check-circle}** Yes | Group |
| `build_timeout` | integer | **{dotted-circle}** No | The maximum amount of time, in seconds, that a job can run. |
| `builds_access_level` | string | **{dotted-circle}** No | One of `disabled`, `private`, or `enabled`. |
| `ci_config_path` | string | **{dotted-circle}** No | The path to CI configuration file. |
| `ci_default_git_depth` | integer | **{dotted-circle}** No | Default number of revisions for [shallow cloning](../ci/pipelines/settings.md#git-shallow-clone). |
| `ci_default_git_depth` | integer | **{dotted-circle}** No | Default number of revisions for [shallow cloning](../ci/pipelines/settings.md#limit-the-number-of-changes-fetched-during-clone). |
| `ci_forward_deployment_enabled` | boolean | **{dotted-circle}** No | When a new deployment job starts, [skip older deployment jobs](../ci/pipelines/settings.md#skip-outdated-deployment-jobs) that are still pending |
| `container_expiration_policy_attributes` | hash | **{dotted-circle}** No | Update the image cleanup policy for this project. Accepts: `cadence` (string), `keep_n` (integer), `older_than` (string), `name_regex` (string), `name_regex_delete` (string), `name_regex_keep` (string), `enabled` (boolean). |
| `container_registry_enabled` | boolean | **{dotted-circle}** No | Enable container registry for this project. |
| [Schedule pipelines](pipelines/schedules.md) | Schedule pipelines to run as often as you need. |
| [Custom path for `.gitlab-ci.yml`](pipelines/settings.md#custom-cicd-configuration-file) | Define a custom path for the CI/CD configuration file. |
| [Custom path for `.gitlab-ci.yml`](pipelines/settings.md#specify-a-custom-cicd-configuration-file) | Define a custom path for the CI/CD configuration file. |
| [Git submodules for CI/CD](git_submodules.md) | Configure jobs for using Git submodules. |
| [SSH keys for CI/CD](ssh_keys/index.md) | Using SSH keys in your CI pipelines. |
| [Pipeline triggers](triggers/index.md) | Trigger pipelines through the API. |
| [Pipelines for Merge Requests](pipelines/merge_request_pipelines.md)| Design a pipeline structure for running a pipeline in merge requests. |
| [SSH keys for CI/CD](ssh_keys/index.md)| Using SSH keys in your CI pipelines. |
| [Pipeline triggers](triggers/index.md)| Trigger pipelines through the API. |
| [Pipelines for Merge Requests](pipelines/merge_request_pipelines.md) | Design a pipeline structure for running a pipeline in merge requests. |
| [Integrate with Kubernetes clusters](../user/project/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
| [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. |
| [`.gitlab-ci.yml` full reference](yaml/index.md) | All the attributes you can use with GitLab CI/CD. |
| [`.gitlab-ci.yml` full reference](yaml/index.md)| All the attributes you can use with GitLab CI/CD. |
Note that certain operations can only be performed according to the
[user](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions.
@@ -14,49 +14,48 @@ You can customize how pipelines run for your project.
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).
## Visibility of pipelines
## Change which users can view your 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:
For public and internal projects, you can change who can see your:
- Pipelines
- 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).
- Job output logs and artifacts are [never visible for Guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
If **Public pipelines** is enabled (default):
To change the visibility of your pipelines and related features:
- 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.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **General pipelines**.
1. Select or clear the **Public pipelines** checkbox.
When it is selected, pipelines and related features are visible:
- For **public** projects, to everyone.
- For **internal** projects, to all logged-in users except [external users](../../user/permissions.md#external-users).
- For **private** projects, to all project members (Guest or higher).
If **Public pipelines** is disabled:
When it is cleared:
- 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.
- For **public** projects, pipelines are visible to everyone. Related features are visible
only to project members (Reporter or higher).
- For **internal** projects, pipelines are visible to all logged in users except [external users](../../user/permissions.md#external-users).
Related features are visible only to project members (Reporter or higher).
- For **private** projects, pipelines and related features are visible to project members (Reporter or higher) only.
## 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. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **General Pipelines**.
1.Check the **Auto-cancel redundant pipelines** checkbox.
1.Click**Save changes**.
1.Select the **Auto-cancel redundant pipelines** checkbox.
1.Select**Save changes**.
Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
running job can be cancelled before it completes.
...
...
@@ -73,12 +72,13 @@ newer one, which may not be what you want.
To avoid this scenario:
1. Go to **Settings > CI/CD**.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **General pipelines**.
1.Check the **Skip outdated deployment jobs** checkbox.
1.Click**Save changes**.
1.Select the **Skip outdated deployment jobs** checkbox.
1.Select**Save changes**.
When enabled, any older deployments job are skipped when a new deployment starts.
Older deployment job are skipped when a new deployment starts.
For more information, see [Deployment safety](../environments/deployment_safety.md).
...
...
@@ -92,78 +92,86 @@ about this and asks for confirmation.
For more information, see [Deployment safety](../environments/deployment_safety.md).
## Custom CI/CD configuration file
## Specify a custom CI/CD configuration file
> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6.
By default we look for the `.gitlab-ci.yml` file in the project's root
directory. If needed, you can specify an alternate path and filename, including locations outside the project.
GitLab expects to find the CI/CD configuration file (`.gitlab-ci.yml`) in the project's root
directory. However, you can specify an alternate filename path, including locations outside the project.
To customize the path:
1. Go to the project's **Settings > CI/CD**.
1. Expand the **General pipelines** section.
1. Provide a value in the **CI/CD configuration file** field.
1. Click **Save changes**.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **General pipelines**.
1. In the **CI/CD configuration file** field, enter the file name, and if:
- The file is not in the root directory, include the path.
- The file is in a different project, include the group and project name.
- The file is on an external site, enter the full URL.
1. Select **Save changes**.
### Custom CI/CD configuration file examples
If the CI/CD configuration file is stored in the repository in a non-default
location, the path must be relative to the root directory. Examples of valid
paths and file names include:
If the CI/CD configuration file is not in the root directory, the path must be relative to it.
For example:
-`.gitlab-ci.yml` (default)
-`.my-custom-file.yml`
-`my/path/.gitlab-ci.yml`
-`my/path/.my-custom-file.yml`
If hosting the CI/CD configuration file on an external site, the URL link must end with `.yml`:
If the CI/CD configuration file is on an external site, the URL must end with `.yml`:
-`http://example.com/generate/ci/config.yml`
If hosting the CI/CD configuration file in a different project in GitLab, the path must be relative
If the CI/CD configuration file is in a different project in GitLab, the path must be relative
to the root directory in the other project. Include the group and project name at the end:
@@ -214,7 +214,7 @@ of your GitLab instance (`.gitlab-ci.yml` if not set):
1. Input the new file and path in the **Default CI/CD configuration file** field.
1. Hit **Save changes** for the changes to take effect.
It is also possible to specify a [custom CI/CD configuration file for a specific project](../../../ci/pipelines/settings.md#custom-cicd-configuration-file).
It is also possible to specify a [custom CI/CD configuration file for a specific project](../../../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file).
