=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 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}
=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 |
|**[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 |
|**[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 |
|**[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 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 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 |
|**[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. |
| `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`. |
| `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_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 |
| `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_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. |
| `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. |
| [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. |
| [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. |
| [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. |
| [Pipeline triggers](triggers/index.md) | Trigger pipelines through the API. |
@@ -14,49 +14,48 @@ You can customize how pipelines run for your project.
...
@@ -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).
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).
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:
For public and internal projects, you can change who can see your:
- 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:
- Pipelines
- Job output logs
- Job output logs
- Job artifacts
- 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.
1. On the top bar, select **Menu > Projects** and find your project.
- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
1. On the left sidebar, select **Settings > CI/CD**.
and related features.
1. Expand **General pipelines**.
- For **private** projects, any project member (Guest or higher) can view the pipelines
1. Select or clear the **Public pipelines** checkbox.
and related features.
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
- For **public** projects, pipelines are visible to everyone. Related features are visible
(Reporter or higher) can access the related features.
only to project members (Reporter or higher).
- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
- For **internal** projects, pipelines are visible to all logged in users except [external users](../../user/permissions.md#external-users).
However, only members (reporter or higher) can access the job related features.
Related features are visible only to project members (Reporter or higher).
- For **private** projects, only project members (reporter or higher)
- For **private** projects, pipelines and related features are visible to project members (Reporter or higher) only.
can view the pipelines or access the related features.
## Auto-cancel redundant pipelines
## 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:
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. Expand **General Pipelines**.
1.Check the **Auto-cancel redundant pipelines** checkbox.
1.Select the **Auto-cancel redundant pipelines** checkbox.
1.Click**Save changes**.
1.Select**Save changes**.
Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
running job can be cancelled before it completes.
running job can be cancelled before it completes.
...
@@ -73,12 +72,13 @@ newer one, which may not be what you want.
...
@@ -73,12 +72,13 @@ newer one, which may not be what you want.
To avoid this scenario:
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. Expand **General pipelines**.
1.Check the **Skip outdated deployment jobs** checkbox.
1.Select the **Skip outdated deployment jobs** checkbox.
1.Click**Save changes**.
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).
For more information, see [Deployment safety](../environments/deployment_safety.md).
...
@@ -92,78 +92,86 @@ about this and asks for confirmation.
...
@@ -92,78 +92,86 @@ about this and asks for confirmation.
For more information, see [Deployment safety](../environments/deployment_safety.md).
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.
> [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
GitLab expects to find the CI/CD configuration file (`.gitlab-ci.yml`) in the project's root
directory. If needed, you can specify an alternate path and filename, including locations outside the project.
directory. However, you can specify an alternate filename path, including locations outside the project.
To customize the path:
To customize the path:
1. Go to the project's **Settings > CI/CD**.
1. On the top bar, select **Menu > Projects** and find your project.
1. Expand the **General pipelines** section.
1. On the left sidebar, select **Settings > CI/CD**.
1. Provide a value in the **CI/CD configuration file** field.
1. Expand **General pipelines**.
1. Click **Save changes**.
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
If the CI/CD configuration file is not in the root directory, the path must be relative to it.
location, the path must be relative to the root directory. Examples of valid
For example:
paths and file names include:
-`.gitlab-ci.yml` (default)
-`.my-custom-file.yml`
-`my/path/.gitlab-ci.yml`
-`my/path/.gitlab-ci.yml`
-`my/path/.my-custom-file.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`
-`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:
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):
...
@@ -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. Input the new file and path in the **Default CI/CD configuration file** field.
1. Hit **Save changes** for the changes to take effect.
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).
