Add latest changes from gitlab-org/gitlab@14-8-stable-eev14.8.0-rc42

1 files changed, 29 insertions, 19 deletions

diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 4530e2675c4..d9ea5498b63 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -415,7 +415,7 @@ and the pipeline is for either:
 - You can use the [`workflow:rules` templates](workflow.md#workflowrules-templates) to import
   a preconfigured `workflow: rules` entry.
 - [Common `if` clauses for `workflow:rules`](workflow.md#common-if-clauses-for-workflowrules).
-- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
+- [Use `rules` to run merge request pipelines](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
 
 #### `workflow:rules:variables`
 
@@ -939,7 +939,7 @@ rspec:
 
 Use `artifacts:untracked` to add all Git untracked files as artifacts (along
 with the paths defined in `artifacts:paths`). `artifacts:untracked` ignores configuration
-in the repository's `.gitignore` file.
+in the repository's `.gitignore`, so matching artifacts in `.gitignore` are included.
 
 **Keyword type**: Job keyword. You can use it only as part of a job or in the
 [`default` section](#default).
@@ -974,7 +974,7 @@ failure.
 
 - `on_success` (default): Upload artifacts only when the job succeeds.
 - `on_failure`: Upload artifacts only when the job fails.
-- `always`: Always upload artifacts. For example, when
+- `always`: Always upload artifacts (except when jobs time out). For example, when
   [uploading artifacts](../unit_test_reports.md#viewing-junit-screenshots-on-gitlab)
   required to troubleshoot failing tests.
 
@@ -1322,12 +1322,14 @@ Use `coverage` with a custom regular expression to configure how code coverage
 is extracted from the job output. The coverage is shown in the UI if at least one
 line in the job output matches the regular expression.
 
-To extract the code coverage value in the matching line, GitLab uses this
-regular expression: `\d+(\.\d+)?`.
+To extract the code coverage value from the match, GitLab uses
+this smaller regular expression: `\d+(\.\d+)?`.
 
 **Possible inputs**:
 
-- A regular expression. Must start and end with `/`.
+- A regular expression. Must start and end with `/`. Must match the coverage number.
+  May match surrounding text as well, so you don't need to use a regular expression character group
+  to capture the exact number.
 
 **Example of `coverage`**:
 
@@ -1339,14 +1341,20 @@ job1:
 
 In this example:
 
-1. GitLab checks the job log for a line that matches the regular expression. A line
-   like `Code coverage: 67.89` would match.
-1. GitLab then checks the line to find a match to `\d+(\.\d+)?`. The sample matching
-   line above gives a code coverage of `67.89`.
+1. GitLab checks the job log for a match with the regular expression. A line
+   like `Code coverage: 67.89% of lines covered` would match.
+1. GitLab then checks the matched fragment to find a match to `\d+(\.\d+)?`.
+   The sample matching line above gives a code coverage of `67.89`.
 
 **Additional details**:
 
-- If there is more than one matched line in the job output, the last line is used.
+- Coverage regular expressions set in `gitlab-ci.yml` take precedence over coverage regular expression set in the
+  [GitLab UI](../pipelines/settings.md#add-test-coverage-results-to-a-merge-request-deprecated).
+- If there is more than one matched line in the job output, the last line is used
+  (the first result of reverse search).
+- If there are multiple matches in a single line, the last match is searched
+  for the coverage number.
+- If there are multiple coverage numbers found in the matched fragment, the first number is used.
 - Leading zeros are removed.
 - Coverage output from [child pipelines](../pipelines/parent_child_pipelines.md)
   is not recorded or displayed. Check [the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/280818)
@@ -1467,7 +1475,7 @@ Use `environment` to define the [environment](../environments/index.md) that a j
 formats:
 
 - Plain text, including letters, digits, spaces, and these characters: `-`, `_`, `/`, `$`, `{`, `}`.
-- CI/CD variables, including predefined, secure, or variables defined in the
+- CI/CD variables, including predefined, project, group, instance, or variables defined in the
   `.gitlab-ci.yml` file. You can't use variables defined in a `script` section.
 
 **Example of `environment`**:
@@ -1496,7 +1504,7 @@ Common environment names are `qa`, `staging`, and `production`, but you can use
 formats:
 
 - Plain text, including letters, digits, spaces, and these characters: `-`, `_`, `/`, `$`, `{`, `}`.
-- CI/CD variables, including predefined, secure, or variables defined in the
+- CI/CD variables, including predefined, project, group, instance, or variables defined in the
   `.gitlab-ci.yml` file. You can't use variables defined in a `script` section.
 
 **Example of `environment:name`**:
@@ -1518,7 +1526,7 @@ Set a URL for an [environment](../environments/index.md).
 **Possible inputs**: A single URL, in one of these formats:
 
 - Plain text, like `https://prod.example.com`.
-- CI/CD variables, including predefined, secure, or variables defined in the
+- CI/CD variables, including predefined, project, group, instance, or variables defined in the
   `.gitlab-ci.yml` file. You can't use variables defined in a `script` section.
 
 **Example of `environment:url`**:
@@ -2366,7 +2374,7 @@ pipeline based on branch names or pipeline types.
   | `chat`                   | For pipelines created by using a [GitLab ChatOps](../chatops/index.md) command. |
   | `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)). |
-  | `merge_requests`         | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/pipelines_for_merged_results.md), and [merge trains](../pipelines/merge_trains.md). |
+  | `merge_requests`         | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
   | `pipelines`              | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/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. |
   | `schedules`              | For [scheduled pipelines](../pipelines/schedules.md). |
@@ -2465,7 +2473,7 @@ Use `changes` in pipelines with the following refs:
 
 - `branches`
 - `external_pull_requests`
-- `merge_requests` (see additional details about [using `only:changes` with pipelines for merge requests](../jobs/job_control.md#use-onlychanges-with-pipelines-for-merge-requests))
+- `merge_requests` (see additional details about [using `only:changes` with merge request pipelines](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines))
 
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
@@ -2507,7 +2515,7 @@ docker build:
 
 - [`only: changes` and `except: changes` examples](../jobs/job_control.md#onlychanges--exceptchanges-examples).
 - If you use `changes` with [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),
-  you should [also use `only:merge_requests`](../jobs/job_control.md#use-onlychanges-with-pipelines-for-merge-requests).
+  you should [also use `only:merge_requests`](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines).
 - [Jobs or pipelines can run unexpectedly when using `only: changes`](../jobs/job_control.md#jobs-or-pipelines-run-unexpectedly-when-using-changes).
 
 #### `only:kubernetes` / `except:kubernetes`
@@ -2654,6 +2662,7 @@ deploystacks: [vultr, processing]
 
 - [Run a one-dimensional matrix of parallel jobs](../jobs/job_control.md#run-a-one-dimensional-matrix-of-parallel-jobs).
 - [Run a matrix of triggered parallel jobs](../jobs/job_control.md#run-a-matrix-of-parallel-trigger-jobs).
+- [Select different runner tags for each parallel matrix job](../jobs/job_control.md#select-different-runner-tags-for-each-parallel-matrix-job).
 
 ### `release`
 
@@ -3079,7 +3088,7 @@ job:
 
 - [Common `if` expressions for `rules`](../jobs/job_control.md#common-if-clauses-for-rules).
 - [Avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines).
-- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
+- [Use `rules` to run merge request pipelines](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
 
 #### `rules:changes`
 
@@ -3569,6 +3578,7 @@ In this example, only runners with *both* the `ruby` and `postgres` tags can run
 **Related topics**:
 
 - [Use tags to control which jobs a runner can run](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run).
+- [Select different runner tags for each parallel matrix job](../jobs/job_control.md#select-different-runner-tags-for-each-parallel-matrix-job).
 
 ### `timeout`
 
@@ -3642,7 +3652,7 @@ trigger_job:
 
 - Jobs with `trigger` can only use a [limited set of keywords](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
   For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
-  or [`after_script`](#after_script).
+  or [`after_script`](#after_script). Also, [`environment`](#environment) is not supported with `trigger`.
 - You [cannot use the API to start `when:manual` trigger jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
 - In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
   can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and