Add latest changes from gitlab-org/gitlab@13-10-stable-eev13.10.0-rc40

4 files changed, 59 insertions, 65 deletions

diff --git a/doc/ci/pipelines/img/pipelines_settings_test_coverage.png b/doc/ci/pipelines/img/pipelines_settings_test_coverage.png
deleted file mode 100644
index 13ed69be810..00000000000
--- a/doc/ci/pipelines/img/pipelines_settings_test_coverage.png
+++ /dev/null
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 6bc0d9bddd9..c2fcbbcf72f 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -6,9 +6,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/ci/pipelines.html'
 type: reference
 ---
 
-# CI/CD pipelines
-
-> Introduced in GitLab 8.8.
+# CI/CD pipelines **(FREE)**
 
 NOTE:
 Watch the
@@ -96,7 +94,7 @@ This table lists the refspecs injected for each pipeline type:
 The refs `refs/heads/<name>` and `refs/tags/<name>` exist in your
 project repository. GitLab generates the special ref `refs/pipelines/<id>` during a
 running pipeline job. This ref can be created even after the associated branch or tag has been
-deleted. It's therefore useful in some features such as [automatically stopping an environment](../environments/index.md#automatically-stopping-an-environment),
+deleted. It's therefore useful in some features such as [automatically stopping an environment](../environments/index.md#stopping-an-environment),
 and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md)
 that might run pipelines after branch deletion.
 
@@ -137,10 +135,10 @@ To execute a pipeline manually:
 1. Navigate to your project's **CI/CD > Pipelines**.
 1. Select the **Run Pipeline** button.
 1. On the **Run Pipeline** page:
-    1. Select the branch to run the pipeline for in the **Create for** field.
+    1. Select the branch or tag to run the pipeline for in the **Run for branch name or tag** field.
     1. Enter any [environment variables](../variables/README.md) required for the pipeline run.
        You can set specific variables to have their [values prefilled in the form](#prefill-variables-in-manual-pipelines).
-    1. Click the **Create pipeline** button.
+    1. Click the **Run pipeline** button.
 
 The pipeline now executes the jobs as configured.
 
@@ -199,8 +197,6 @@ For each `var` or `file_var`, a key and value are required.
 
 ### Add manual interaction to your pipeline
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7931) in GitLab 8.15.
-
 Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) keyword,
 allow you to require manual interaction before moving forward in the pipeline.
 
@@ -208,7 +204,7 @@ You can do this straight from the pipeline graph. Just click the play button
 to execute that particular job.
 
 For example, your pipeline might start automatically, but it requires manual action to
-[deploy to production](../environments/index.md#configuring-manual-deployments). In the example below, the `production`
+[deploy to production](../environments/index.md#configure-manual-deployments). In the example below, the `production`
 stage has a job with a manual action.
 
 ![Pipelines example](img/pipelines.png)
@@ -324,8 +320,6 @@ runners do not use regular runners, they must be tagged accordingly.
 
 ## Visualize pipelines
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5742) in GitLab 8.11.
-
 Pipelines can be complex structures with many sequential and parallel jobs.
 
 To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines
diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md
index a8e310c1f0d..752e2a97fad 100644
--- a/doc/ci/pipelines/schedules.md
+++ b/doc/ci/pipelines/schedules.md
@@ -36,7 +36,7 @@ Otherwise the pipeline is not created.
 
 To schedule a pipeline for project:
 
-1. Navigate to the project's **CI / CD > Schedules** page.
+1. Navigate to the project's **CI/CD > Schedules** page.
 1. Click the **New schedule** button.
 1. Fill in the **Schedule a new pipeline** form.
 1. Click the **Save pipeline schedule** button.
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 32221b78039..e607bae53bd 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -6,7 +6,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.h
 type: reference, howto
 ---
 
-# Pipeline settings
+# Pipeline settings **(FREE)**
 
 To reach the pipelines settings navigate to your project's
 **Settings > CI/CD**.
@@ -17,6 +17,11 @@ The following settings can be configured per project.
 For an overview, 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:
+
+- [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).
+
 ## Git strategy
 
 With Git strategy, you can choose the default way your repository is fetched
@@ -24,7 +29,7 @@ from GitLab in a job.
 
 There are two options. Using:
 
-- `git clone`, which is slower since it clones the repository from scratch
+- `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).
@@ -70,20 +75,19 @@ For information about setting a maximum artifact size for a project, see
 
 ## Custom CI/CD configuration path
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12509) in GitLab 9.4.
-> - [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
 directory. If needed, you can specify an alternate path and filename, including locations outside the project.
 
 To customize the path:
 
-1. Go to the project's **Settings > CI / CD**.
+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**.
 
-If the CI configuration is stored within the repository in a non-default
+If the CI configuration 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:
 
@@ -96,7 +100,7 @@ If hosting the CI configuration on an external site, the URL link must end with
 
 - `http://example.com/generate/ci/config.yml`
 
-If hosting the CI configuration in a different project within GitLab, the path must be relative
+If hosting the CI configuration 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:
 
 - `.gitlab-ci.yml@mygroup/another-project`
@@ -114,10 +118,10 @@ able to edit it.
 ## Test coverage parsing
 
 If you use test coverage in your code, GitLab can capture its output in the
-job log using a regular expression. In the pipelines settings, search for the
-"Test coverage parsing" section.
+job log using a regular expression.
 
-![Pipelines settings test coverage](img/pipelines_settings_test_coverage.png)
+In your project, go to **Settings > CI/CD** and expand the **General pipelines**
+section. Enter the regular expression in the **Test coverage parsing** field.
 
 Leave blank if you want to disable it or enter a Ruby regular expression. You
 can use <https://rubular.com> to test your regex. The regex returns the **last**
@@ -133,19 +137,21 @@ averaged.
 
 <!-- vale gitlab.Spelling = NO -->
 
-| Coverage Tool                                  | Sample regular expression |
-|------------------------------------------------|---------------------------|
-| Simplecov (Ruby)                               | `\(\d+.\d+\%\) covered` |
-| pytest-cov (Python)                            | `^TOTAL.+?(\d+\%)$` |
+| Coverage Tool                                  | Sample regular expression                     |
+|------------------------------------------------|-----------------------------------------------|
+| Simplecov (Ruby)                               | `\(\d+.\d+\%\) covered`                       |
+| pytest-cov (Python)                            | `^TOTAL.+?(\d+\%)$`                           |
 | Scoverage (Scala)                              | `Statement coverage[A-Za-z\.*]\s*:\s*([^%]+)` |
-| `phpunit --coverage-text --colors=never` (PHP) | `^\s*Lines:\s*\d+.\d+\%` |
-| gcovr (C/C++)                                  | `^TOTAL.*\s+(\d+\%)$` |
-| `tap --coverage-report=text-summary` (NodeJS)  | `^Statements\s*:\s*([^%]+)` |
-| `nyc npm test` (NodeJS)                        | `All files[^|]*\|[^|]*\s+([\d\.]+)` |
-| excoveralls (Elixir)                           | `\[TOTAL\]\s+(\d+\.\d+)%` |
-| `mix test --cover` (Elixir)                    | `\d+.\d+\%\s+\|\s+Total` |
-| JaCoCo (Java/Kotlin)                           | `Total.*?([0-9]{1,3})%` |
-| `go test -cover` (Go)                          | `coverage: \d+.\d+% of statements` |
+| `phpunit --coverage-text --colors=never` (PHP) | `^\s*Lines:\s*\d+.\d+\%`                      |
+| gcovr (C/C++)                                  | `^TOTAL.*\s+(\d+\%)$`                         |
+| `tap --coverage-report=text-summary` (NodeJS)  | `^Statements\s*:\s*([^%]+)`                   |
+| `nyc npm test` (NodeJS)                        | `All files[^|]*\|[^|]*\s+([\d\.]+)`           |
+| excoveralls (Elixir)                           | `\[TOTAL\]\s+(\d+\.\d+)%`                     |
+| `mix test --cover` (Elixir)                    | `\d+.\d+\%\s+\|\s+Total`                      |
+| JaCoCo (Java/Kotlin)                           | `Total.*?([0-9]{1,3})%`                       |
+| `go test -cover` (Go)                          | `coverage: \d+.\d+% of statements`            |
+| .Net (OpenCover)                               | `(Visited Points).*\((.*)\)`                  |
+| .Net (`dotnet test` line coverage)             | `Total\s*\|\s*(\d+\.?\d+)`                    |
 
 <!-- vale gitlab.Spelling = YES -->
 
@@ -157,11 +163,13 @@ averaged.
 To see the evolution of your project code coverage over time,
 you can view a graph or download a CSV file with this data. From your project:
 
-1. Go to **{chart}** **Project Analytics > Repository** to see the historic data for each job listed in the dropdown above the graph.
+1. Go to **Project Analytics > Repository** to see the historic data for each job listed in the dropdown above the graph.
 1. If you want a CSV file of that data, click **Download raw data (`.csv`)**
 
 ![Code coverage graph of a project over time](img/code_coverage_graph_v13_1.png)
 
+Code coverage data is also [available at the group level](../../user/group/repositories_analytics/index.md).
+
 ### Removing color codes
 
 Some test coverage tools output with ANSI color codes that aren't
@@ -215,11 +223,9 @@ If **Public pipelines** is disabled:
 
 ## Auto-cancel redundant pipelines
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9362) in GitLab 9.1.
-
 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. Go to **Settings > CI/CD**.
 1. Expand **General Pipelines**.
 1. Check the **Auto-cancel redundant pipelines** checkbox.
 1. Click **Save changes**.
@@ -232,14 +238,14 @@ running job can be cancelled before it completes.
 > [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 within the same time frame.
+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. Go to **Settings > CI/CD**.
 1. Expand **General pipelines**.
 1. Check the **Skip outdated deployment jobs** checkbox.
 1. Click **Save changes**.
@@ -272,15 +278,15 @@ pages.
 
 ### Pipeline status badge
 
-Depending on the status of your job, a badge can have the following values:
+Depending on the status of your pipeline, a badge can have the following values:
 
-- pending
-- running
-- passed
-- failed
-- skipped
-- canceled
-- unknown
+- `pending`
+- `running`
+- `passed`
+- `failed`
+- `skipped`
+- `canceled`
+- `unknown`
 
 You can access a pipeline status badge image using the following link:
 
@@ -321,29 +327,27 @@ into your `README.md`:
 
 Pipeline badges can be rendered in different styles by adding the `style=style_name` parameter to the URL. Two styles are available:
 
-#### Flat (default)
+- Flat (default):
 
-```plaintext
-https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
-```
+  ```plaintext
+  https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
+  ```
 
-![Badge flat style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat)
+  ![Badge flat style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat)
 
-#### Flat square
+- Flat square ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30120) in GitLab 11.8):
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30120) in GitLab 11.8.
+  ```plaintext
+  https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
+  ```
 
-```plaintext
-https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
-```
-
-![Badge flat square style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat-square)
+  ![Badge flat square style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat-square)
 
 ### Custom badge text
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17555) in GitLab 13.1.
 
-The text for a badge can be customized. This can be useful to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the `key_text=custom_text` and `key_width=custom_key_width` parameters to the URL:
+The text for a badge can be customized to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the `key_text=custom_text` and `key_width=custom_key_width` parameters to the URL:
 
 ```plaintext
 https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130
@@ -351,10 +355,6 @@ https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_te
 
 ![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130)
 
-## CI/CD Variables
-
-[CI/CD variables](../variables/README.md) can be set to be available to a runner.
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues