kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2021-06-24 03:07:19 +00:00
parent 1d78b1f77a
commit 27037055ab
10 changed files with 120 additions and 157 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
doc/administration/compliance.md
View file

@ -17,6 +17,7 @@ relevant compliance standards.
|----------|:-----------:|:-----------:|:-------------:| |----------|:-----------:|:-----------:|:-------------:|
|**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab. | Free+ | **{dotted-circle}** No | Instance | |**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab. | Free+ | **{dotted-circle}** No | Instance |
|**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. | Free+ | **{check-circle}** Yes | Instance, Group, Project | |**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. | Free+ | **{check-circle}** Yes | Instance, Group, Project |
|**[Generate reports on permission levels of users](../user/admin_area/index.md#user-permission-export)**<br>Administrators can generate a report listing all users' access permissions for groups and projects in the instance. | Premium+ | **{dotted-circle}** No | Instance |
|**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic. | Free+ | **{dotted-circle}** No | Instance | |**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic. | Free+ | **{dotted-circle}** No | Instance |
|**[Email all users of a project, group, or entire server](../tools/email.md)**<br>An administrator can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades. | Premium+ | **{dotted-circle}** No | Instance | |**[Email all users of a project, group, or entire server](../tools/email.md)**<br>An administrator can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades. | Premium+ | **{dotted-circle}** No | Instance |
|**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system. | Premium+ | **{dotted-circle}** No | Instance | |**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system. | Premium+ | **{dotted-circle}** No | Instance |

2
doc/ci/jobs/job_control.md
View file

@ -222,7 +222,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
| `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). | | `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). |
| `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). | | `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
| `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. | | `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. |
| `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#triggering-multi-project-pipelines-through-api), or the [`trigger`](../yaml/README.md#trigger) keyword. | | `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/README.md#trigger) keyword. |
| `push` | For pipelines triggered by a `git push` event, including for branches and tags. | | `push` | For pipelines triggered by a `git push` event, including for branches and tags. |
| `schedule` | For [scheduled pipelines](../pipelines/schedules.md). | | `schedule` | For [scheduled pipelines](../pipelines/schedules.md). |
| `trigger` | For pipelines created by using a [trigger token](../triggers/README.md#trigger-token). | | `trigger` | For pipelines created by using a [trigger token](../triggers/README.md#trigger-token). |

221
doc/ci/multi_project_pipelines.md
View file

@ -10,79 +10,39 @@ type: reference
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8. > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
You can set up [GitLab CI/CD](README.md) across multiple projects, so that a pipeline You can set up [GitLab CI/CD](README.md) across multiple projects, so that a pipeline
in one project can trigger a pipeline in another project. in one project can trigger a pipeline in another project. You can visualize the entire pipeline
in one place, including all cross-project interdependencies.
For example, you might deploy your web application from three different projects in GitLab.
Each project has its own build, test, and deploy process. With multi-project pipelines you can
visualize the entire pipeline, including all build and test stages for all three projects.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an overview see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84). For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
GitLab CI/CD is a powerful continuous integration tool that works not only per project, Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those
but also across projects with multi-project pipelines. with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
Learn more in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
at GitLab@learn, in the Continuous Integration section.
Multi-project pipelines are useful for larger products that require cross-project inter-dependencies, such as those If you trigger a pipeline in a downstream private project, the name of the project
adopting a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/). and the status of the pipeline is visible in the upstream project's pipelines page.
Make sure that there are no confidentiality problems if you have a public project
that can trigger downstream pipelines in a private project.
Cross-functional development teams can use cross-pipeline ## Create multi-project pipelines
triggering to trigger multiple pipelines for different microservices projects. Learn more
in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
at GitLab@learn, in the Continuous Integration (CI) section.
Additionally, it's possible to visualize the entire pipeline, including all cross-project To create multi-project pipelines, you can:
inter-dependencies. **(PREMIUM)**
## Use cases - [Use the CI/CD configuration syntax](#create-multi-project-pipelines-in-your-gitlab-ciyml-file).
- [Use the API](#create-multi-project-pipelines-by-using-the-api).
Let's assume you deploy your web app from different projects in GitLab: ### Create multi-project pipelines in your `.gitlab-ci.yml` file
- One for the free version, which has its own pipeline that builds and tests your app
- One for the paid version add-ons, which also pass through builds and tests
- One for the documentation, which also builds, tests, and deploys with an SSG
With Multi-Project Pipelines you can visualize the entire pipeline, including all build and test stages for the three projects.
## Multi-project pipeline visualization **(PREMIUM)**
When you configure GitLab CI/CD for your project, you can visualize the stages of your
[jobs](pipelines/index.md#configure-a-pipeline) on a [pipeline graph](pipelines/index.md#visualize-pipelines).
![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)
In the Merge Request Widget, multi-project pipeline mini-graphs are displayed,
and when hovering or tapping (on touchscreen devices) they expand and are shown adjacent to each other.
![Multi-project mini graph](img/multi_pipeline_mini_graph.gif)
## Triggering multi-project pipelines through API
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
When you use the [`CI_JOB_TOKEN` to trigger pipelines](triggers/README.md#ci-job-token), GitLab
recognizes the source of the job token, and thus internally ties these pipelines
together, allowing you to visualize their relationships on pipeline graphs.
These relationships are displayed in the pipeline graph by showing inbound and
outbound connections for upstream and downstream pipeline dependencies.
When using:
- CI/CD Variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is
`pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
- [`only/except`](yaml/README.md#only--except) to control job behavior, use the
`pipelines` keyword.
## Creating multi-project pipelines from `.gitlab-ci.yml`
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8. > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
### Triggering a downstream pipeline using a bridge job When you create a multi-project pipeline in your `.gitlab-ci.yml` file,
you create what is called a "trigger job". For example:
Before GitLab 11.8, it was necessary to implement a pipeline job that was
responsible for making the API request [to trigger a pipeline](#triggering-multi-project-pipelines-through-api)
in a different project.
In GitLab 11.8, GitLab provides a new CI/CD configuration syntax to make this
task easier, and avoid needing GitLab Runner for triggering cross-project
pipelines. The following illustrates configuring a bridge job:
```yaml ```yaml
rspec: rspec:
@ -96,38 +56,39 @@ staging:
trigger: my/deployment trigger: my/deployment
``` ```
In the example above, as soon as the `rspec` job succeeds in the `test` stage, In this example, after the `rspec` job succeeds in the `test` stage,
the `staging` bridge job is started. The initial status of this the `staging` trigger job starts. The initial status of this
job is `pending`. GitLab then creates a downstream pipeline in the job is `pending`.
`my/deployment` project and, as soon as the pipeline is created, the
`staging` job succeeds. `my/deployment` is a full path to that project.
The user that created the upstream pipeline needs to have access rights to the GitLab then creates a downstream pipeline in the
downstream project (`my/deployment` in this case). If a downstream project is `my/deployment` project and, as soon as the pipeline is created, the
not found, or a user does not have access rights to create a pipeline there, `staging` job succeeds. The full path to the project is `my/deployment`.
You can view the status for the pipeline, or you can display
[the downstream pipeline's status instead](#mirror-status-of-a-triggered-pipeline-in-the-trigger-job).
The user that creates the upstream pipeline must be able to create pipelines in the
downstream project (`my/deployment`) too. If the downstream project is not found,
or the user does not have [permission](../user/permissions.md) to create a pipeline there,
the `staging` job is marked as _failed_. the `staging` job is marked as _failed_.
When using: Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](yaml/README.md).
The keywords available for use in trigger jobs are:
- CI/CD variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of - [`trigger`](yaml/README.md#trigger)
the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is - [`stage`](yaml/README.md#stage)
`pipeline` for multi-project pipelines triggered with a bridge job (using the - [`allow_failure`](yaml/README.md#allow_failure)
[`trigger:`](yaml/README.md#trigger) keyword). - [`rules`](yaml/README.md#rules)
- [`only/except`](yaml/README.md#only--except) to control job behavior, use the - [`only` and `except`](yaml/README.md#only--except)
`pipelines` keyword. - [`when`](yaml/README.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
- [`extends`](yaml/README.md#extends)
- [`needs`](yaml/README.md#needs)
In the example, `staging` is marked as successful as soon as a downstream pipeline #### Specify a downstream pipeline branch
gets created. If you want to display the downstream pipeline's status instead, see
[Mirroring status from triggered pipeline](#mirroring-status-from-triggered-pipeline).
NOTE: You can specify a branch name for the downstream pipeline to use.
Bridge jobs [do not support every configuration keyword](#limitations) that can be used GitLab uses the commit on the head of the branch to
with other jobs. If a user tries to use unsupported configuration keywords, YAML create the downstream pipeline.
validation fails on pipeline creation.
### Specifying a downstream pipeline branch
It is possible to specify a branch name that a downstream pipeline uses:
```yaml ```yaml
rspec: rspec:
@ -145,25 +106,18 @@ Use:
- The `project` keyword to specify the full path to a downstream project. - The `project` keyword to specify the full path to a downstream project.
- The `branch` keyword to specify the name of a branch in the project specified by `project`. - The `branch` keyword to specify the name of a branch in the project specified by `project`.
[From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is [In GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/10126) and later, variable expansion is
supported. supported.
GitLab uses a commit that is on the head of the branch when Pipelines triggered on a protected branch in a downstream project use the [role](../user/permissions.md)
creating a downstream pipeline.
NOTE:
Pipelines triggered on a protected branch in a downstream project use the [permissions](../user/permissions.md)
of the user that ran the trigger job in the upstream project. If the user does not of the user that ran the trigger job in the upstream project. If the user does not
have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See
[pipeline security for protected branches](pipelines/index.md#pipeline-security-on-protected-branches). [pipeline security for protected branches](pipelines/index.md#pipeline-security-on-protected-branches).
### Passing CI/CD variables to a downstream pipeline #### Pass CI/CD variables to a downstream pipeline by using the `variables` keyword
#### With the `variables` keyword
Sometimes you might want to pass CI/CD variables to a downstream pipeline. Sometimes you might want to pass CI/CD variables to a downstream pipeline.
You can do that using the `variables` keyword, just like you would when You can do that by using the `variables` keyword, just like you would for any other job.
defining a regular job.
```yaml ```yaml
rspec: rspec:
@ -206,14 +160,14 @@ downstream-job:
``` ```
In this scenario, the `UPSTREAM_BRANCH` variable with a value related to the In this scenario, the `UPSTREAM_BRANCH` variable with a value related to the
upstream pipeline is passed to the `downstream-job` job, and is available upstream pipeline is passed to the `downstream-job` job. It is available
within the context of all downstream builds. in the context of all downstream builds.
Upstream pipelines take precedence over downstream ones. If there are two Upstream pipelines take precedence over downstream ones. If there are two
variables with the same name defined in both upstream and downstream projects, variables with the same name defined in both upstream and downstream projects,
the ones defined in the upstream project take precedence. the ones defined in the upstream project take precedence.
#### With variable inheritance #### Pass CI/CD variables to a downstream pipeline by using variable inheritance
You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs). You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs).
@ -253,13 +207,24 @@ test:
artifacts: true artifacts: true
``` ```
### Mirroring status from triggered pipeline #### Use `rules` or `only`/`except` with multi-project pipelines
You can use CI/CD variables or the [`rules`](yaml/README.md#rulesif) keyword to
[control job behavior](jobs/job_control.md) for multi-project pipelines. When a
downstream pipeline is triggered with the [`trigger`](yaml/README.md#trigger) keyword,
the value of the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md)
is `pipeline` for all its jobs.
If you use [`only/except`](yaml/README.md#only--except) to control job behavior, use the
[`pipelines`](yaml/README.md#onlyrefs--exceptrefs) keyword.
#### Mirror status of a triggered pipeline in the trigger job
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11238) in GitLab Premium 12.3. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11238) in GitLab Premium 12.3.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8. > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
You can mirror the pipeline status from the triggered pipeline to the source You can mirror the pipeline status from the triggered pipeline to the source
bridge job by using `strategy: depend`. For example: trigger job by using `strategy: depend`. For example:
```yaml ```yaml
trigger_job: trigger_job:
@ -268,7 +233,7 @@ trigger_job:
strategy: depend strategy: depend
``` ```
### Mirroring status from upstream pipeline #### Mirror status from upstream pipeline
You can mirror the pipeline status from an upstream pipeline to a bridge job by You can mirror the pipeline status from an upstream pipeline to a bridge job by
using the `needs:pipeline` keyword. The latest pipeline status from the default branch is using the `needs:pipeline` keyword. The latest pipeline status from the default branch is
@ -283,24 +248,24 @@ upstream_bridge:
pipeline: other/project pipeline: other/project
``` ```
### Limitations ### Create multi-project pipelines by using the API
Bridge jobs are a little different from regular jobs. It is not > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
possible to use exactly the same configuration syntax as when defining regular jobs
that are picked by a runner.
Some features are not implemented yet. For example, support for environments. When you use the [`CI_JOB_TOKEN` to trigger pipelines](triggers/README.md#ci-job-token),
GitLab recognizes the source of the job token. The pipelines become related,
so you can visualize their relationships on pipeline graphs.
[Configuration keywords](yaml/README.md) available for bridge jobs are: These relationships are displayed in the pipeline graph by showing inbound and
outbound connections for upstream and downstream pipeline dependencies.
- `trigger` (to define a downstream pipeline trigger) When using:
- `stage`
- `allow_failure` - CI/CD Variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
- [`rules`](yaml/README.md#rules) the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is
- `only` and `except` `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
- `when` (only with `on_success`, `on_failure`, and `always` values) - [`only/except`](yaml/README.md#only--except) to control job behavior, use the
- `extends` `pipelines` keyword.
- `needs`
## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)** ## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
@ -320,13 +285,17 @@ number of upstream pipeline subscriptions is 2 by default, for both the upstream
downstream projects. This [application limit](../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project) can be changed on self-managed instances by a GitLab administrator. downstream projects. This [application limit](../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project) can be changed on self-managed instances by a GitLab administrator.
The upstream project needs to be [public](../public_access/public_access.md) The upstream project needs to be [public](../public_access/public_access.md)
and the user must have [developer permissions](../user/permissions.md#project-members-permissions) and the user must have the [developer role](../user/permissions.md#project-members-permissions)
for the upstream project. in the upstream project.
## Downstream private projects confidentiality concern ## Multi-project pipeline visualization **(PREMIUM)**
If you trigger a pipeline in a downstream private project, the name of the project When you configure GitLab CI/CD for your project, you can visualize the stages of your
and the status of the pipeline is visible in the upstream project's pipelines page. [jobs](pipelines/index.md#configure-a-pipeline) on a [pipeline graph](pipelines/index.md#visualize-pipelines).
If you have a public project that can trigger downstream pipelines in a private ![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)
project, make sure to check that there are no confidentiality problems.
In the Merge Request Widget, multi-project pipeline mini-graphs are displayed.
They expand and are shown adjacent to each other when hovering (or tapping on touchscreen devices).
![Multi-project mini graph](img/multi_pipeline_mini_graph.gif)

9
doc/ci/parent_child_pipelines.md
View file

@ -85,7 +85,7 @@ microservice_a:
The maximum number of entries that are accepted for `trigger:include:` is three. The maximum number of entries that are accepted for `trigger:include:` is three.
Similar to [multi-project pipelines](multi_project_pipelines.md#mirroring-status-from-triggered-pipeline), Similar to [multi-project pipelines](multi_project_pipelines.md#mirror-status-of-a-triggered-pipeline-in-the-trigger-job),
we can set the parent pipeline to depend on the status of the child pipeline upon completion: we can set the parent pipeline to depend on the status of the child pipeline upon completion:
```yaml ```yaml
@ -185,5 +185,8 @@ For an overview, see [Nested Dynamic Pipelines](https://youtu.be/C5j3ju9je2M).
## Pass CI/CD variables to a child pipeline ## Pass CI/CD variables to a child pipeline
You can [pass CI/CD variables to a downstream pipeline](multi_project_pipelines.md#passing-cicd-variables-to-a-downstream-pipeline) You can pass CI/CD variables to a downstream pipeline using the same methods as
the same way as for multi-project pipelines. multi-project pipelines:
- [By using the `variable` keyword](multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword).
- [By using variable inheritance](multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance).

3
doc/ci/variables/README.md
View file

@ -581,7 +581,8 @@ You can override the value of a variable when you:
1. Run a job manually in the UI. 1. Run a job manually in the UI.
1. Use [push options](../../user/project/push_options.md#push-options-for-gitlab-cicd). 1. Use [push options](../../user/project/push_options.md#push-options-for-gitlab-cicd).
1. Trigger a pipeline by using [the API](../triggers/README.md#making-use-of-trigger-variables). 1. Trigger a pipeline by using [the API](../triggers/README.md#making-use-of-trigger-variables).
1. Pass variables to a [downstream pipeline](../multi_project_pipelines.md#passing-cicd-variables-to-a-downstream-pipeline). 1. Pass variables to a downstream pipeline [by using the `variable` keyword](../multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword)
or [by using variable inheritance](../multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance).
The pipeline variables declared in these events take [priority over other variables](#cicd-variable-precedence). The pipeline variables declared in these events take [priority over other variables](#cicd-variable-precedence).

8
doc/ci/yaml/README.md
View file

@ -1336,7 +1336,7 @@ pipeline based on branch names or pipeline types.
| `external` | When you use CI services other than GitLab. | | `external` | When you use CI services other than GitLab. |
| `external_pull_requests` | When an external pull request on GitHub is created or updated (See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)). | | `external_pull_requests` | When an external pull request on GitHub is created or updated (See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)). |
| `merge_requests` | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). | | `merge_requests` | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
| `pipelines` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#triggering-multi-project-pipelines-through-api), or the [`trigger`](#trigger) keyword. | | `pipelines` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](#trigger) keyword. |
| `pushes` | For pipelines triggered by a `git push` event, including for branches and tags. | | `pushes` | For pipelines triggered by a `git push` event, including for branches and tags. |
| `schedules` | For [scheduled pipelines](../pipelines/schedules.md). | | `schedules` | For [scheduled pipelines](../pipelines/schedules.md). |
| `tags` | When the Git reference for a pipeline is a tag. | | `tags` | When the Git reference for a pipeline is a tag. |
@ -3561,13 +3561,13 @@ deploystacks: [vultr, data]
Use `trigger` to define a downstream pipeline trigger. When GitLab starts a `trigger` job, Use `trigger` to define a downstream pipeline trigger. When GitLab starts a `trigger` job,
a downstream pipeline is created. a downstream pipeline is created.
Jobs with `trigger` can only use a [limited set of keywords](../multi_project_pipelines.md#limitations). Jobs with `trigger` can only use a [limited set of keywords](../multi_project_pipelines.md#create-multi-project-pipelines-in-your-gitlab-ciyml-file).
For example, you can't run commands with [`script`](#script), [`before_script`](#before_script), For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
or [`after_script`](#after_script). or [`after_script`](#after_script).
You can use this keyword to create two different types of downstream pipelines: You can use this keyword to create two different types of downstream pipelines:
- [Multi-project pipelines](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml) - [Multi-project pipelines](../multi_project_pipelines.md#create-multi-project-pipelines-in-your-gitlab-ciyml-file)
- [Child pipelines](../parent_child_pipelines.md) - [Child pipelines](../parent_child_pipelines.md)
[In GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) and later, you can [In GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) and later, you can
@ -3642,7 +3642,7 @@ trigger_job:
include: path/to/child-pipeline.yml include: path/to/child-pipeline.yml
``` ```
Similar to [multi-project pipelines](../multi_project_pipelines.md#mirroring-status-from-triggered-pipeline), Similar to [multi-project pipelines](../multi_project_pipelines.md#mirror-status-of-a-triggered-pipeline-in-the-trigger-job),
it's possible to mirror the status from a triggered pipeline: it's possible to mirror the status from a triggered pipeline:
```yaml ```yaml

12
doc/development/api_graphql_styleguide.md
View file

@ -674,26 +674,24 @@ support for the former argument style, remove the `Deprecation`:
DEPRECATIONS = [].freeze DEPRECATIONS = [].freeze
``` ```
During the deprecation period the API accepts these values for the argument: During the deprecation period the API will accept either of these formats for the argument value:
Formatted as either:
- `"gid://gitlab/PrometheusService/1"` - `"gid://gitlab/PrometheusService/1"`
- `"gid://gitlab/Integrations::Prometheus/1"` - `"gid://gitlab/Integrations::Prometheus/1"`
And query signatures recognizes the type under the old and new type names, accepting either: The API will also accept these types in the query signature for the argument:
- `PrometheusServiceID` - `PrometheusServiceID`
- `IntegrationsPrometheusID` - `IntegrationsPrometheusID`
NOTE: NOTE:
Although queries that use the old name (`PrometheusServiceID` in this example) would be Although queries that use the old type (`PrometheusServiceID` in this example) will be
considered valid and executable by the API, validator tools would consider them invalid. considered valid and executable by the API, validator tools will consider them to be invalid.
This is because we are deprecating using a bespoke method outside of the This is because we are deprecating using a bespoke method outside of the
[`@deprecated` directive](https://spec.graphql.org/June2018/#sec--deprecated), so validators are not [`@deprecated` directive](https://spec.graphql.org/June2018/#sec--deprecated), so validators are not
aware of the support. aware of the support.
The documentation mentions that the old Global ID style is now deprecated. The documentation will mention that the old Global ID style is now deprecated.
See also [Aliasing and deprecating mutations](#aliasing-and-deprecating-mutations). See also [Aliasing and deprecating mutations](#aliasing-and-deprecating-mutations).

17
lib/gitlab/metrics/dashboard/finder.rb
View file

@ -7,14 +7,9 @@ module Gitlab
module Metrics module Metrics
module Dashboard module Dashboard
class Finder class Finder
# Dashboards that should not be part of the list of all dashboards PREDEFINED_DASHBOARD_LIST = [
# displayed on the metrics dashboard page. ::Metrics::Dashboard::PodDashboardService,
PREDEFINED_DASHBOARD_EXCLUSION_LIST = [ ::Metrics::Dashboard::SystemDashboardService
# This dashboard is only useful in the self monitoring project.
::Metrics::Dashboard::SelfMonitoringDashboardService,
# This dashboard is displayed on the K8s cluster settings health page.
::Metrics::Dashboard::ClusterDashboardService
].freeze ].freeze
class << self class << self
@ -90,11 +85,7 @@ module Gitlab
return [self_monitoring_service] return [self_monitoring_service]
end end
predefined_dashboard_services PREDEFINED_DASHBOARD_LIST
end
def predefined_dashboard_services
::Metrics::Dashboard::PredefinedDashboardService.descendants - PREDEFINED_DASHBOARD_EXCLUSION_LIST
end end
def system_service def system_service

2
qa/qa/service/cluster_provider/k3s.rb
View file

@ -9,7 +9,7 @@ module QA
end end
def setup def setup
@k3s = Service::DockerRun::K3s.init do |k3s| @k3s = Service::DockerRun::K3s.new.tap do |k3s|
k3s.remove! k3s.remove!
k3s.register! k3s.register!

2
qa/qa/specs/features/browser_ui/3_create/repository/push_mirroring_over_http_spec.rb
View file

@ -3,7 +3,7 @@
module QA module QA
RSpec.describe 'Create' do RSpec.describe 'Create' do
describe 'Push mirror a repository over HTTP' do describe 'Push mirror a repository over HTTP' do
it 'configures and syncs a (push) mirrored repository', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/414' do it 'configures and syncs a (push) mirrored repository', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/414', quarantine: { issue: 'https://gitlab.com/gitlab-org/gitlab/-/issues/334458', type: :investigating } do
Runtime::Browser.visit(:gitlab, Page::Main::Login) Runtime::Browser.visit(:gitlab, Page::Main::Login)
Page::Main::Login.perform(&:sign_in_using_credentials) Page::Main::Login.perform(&:sign_in_using_credentials)