Add latest changes from gitlab-org/gitlab@13-0-stable-ee

9 files changed, 143 insertions, 108 deletions

diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md
index 755bf0447e3..427761281f6 100644
--- a/doc/user/project/merge_requests/accessibility_testing.md
+++ b/doc/user/project/merge_requests/accessibility_testing.md
@@ -18,6 +18,23 @@ measuring the accessibility of web sites, and has built a simple
 This job outputs accessibility violations, warnings, and notices for each page
 analyzed to a file called `accessibility`.
 
+## Accessibility Merge Request widget
+
+[Since GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/39425), in addition to the report artifact that is created, GitLab will also show the
+Accessibility Report in the merge request widget area:
+
+![Accessibility Merge Request Widget](img/accessibility_mr_widget_v13_0.png)
+
+This widget comes with the `:accessibility_report_view` feature flag disabled by default while we test feature stability.
+Once we have determined the widget is stable, this feature will be enabled by default.
+
+To enable this feature, ask a GitLab administrator with [Rails console access](../../../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) to run the
+following command:
+
+```ruby
+Feature.enable(:accessibility_report_view)
+```
+
 ## Configure Accessibility Testing
 
 This example shows how to run [pa11y](https://pa11y.org/)
@@ -46,10 +63,13 @@ Pa11y against the webpages defined in `a11y_urls`, and builds an HTML report for
 
 The report for each URL is saved as an artifact that can be [viewed directly in your browser](../../../ci/pipelines/job_artifacts.md#browsing-artifacts).
 
-A single `accessibility.json` artifact is created and saved along with the individual HTML reports.
+A single `gl-accessibility.json` artifact is created and saved along with the individual HTML reports.
 It includes report data for all URLs scanned.
 
 NOTE: **Note:**
+For GitLab 12.10 and earlier, the [artifact generated is named `accessibility.json`](https://gitlab.com/gitlab-org/ci-cd/accessibility/-/merge_requests/9).
+
+NOTE: **Note:**
 For GitLab versions earlier than 12.9, you can use `include:remote` and use a
 link to the [current template in `master`](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
 
diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md
index 1bca5d2a212..0fa3d7be265 100644
--- a/doc/user/project/merge_requests/browser_performance_testing.md
+++ b/doc/user/project/merge_requests/browser_performance_testing.md
@@ -6,55 +6,50 @@ type: reference, howto
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3507) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.3.
 
-If your application offers a web interface and you are using
+If your application offers a web interface and you're using
 [GitLab CI/CD](../../../ci/README.md), you can quickly determine the performance
 impact of pending code changes.
 
 ## Overview
 
 GitLab uses [Sitespeed.io](https://www.sitespeed.io), a free and open source
-tool for measuring the performance of web sites, and has built a simple
-[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance)
-which outputs the results in a file called `performance.json`. This plugin
-outputs the performance score for each page that is analyzed.
-
+tool, for measuring the performance of web sites. GitLab has built a simple
+[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance) which outputs
+the performance score for each page analyzed in a file called `performance.json`.
 The [Sitespeed.io performance score](https://examples.sitespeed.io/6.0/2017-11-23-23-43-35/help.html)
-is a composite value based on best practices, and we will be expanding support
-for [additional metrics](https://gitlab.com/gitlab-org/gitlab/issues/4370)
-in a future release.
+is a composite value based on best practices.
 
-Going a step further, GitLab can show the Performance report right
-in the merge request widget area (see below).
+GitLab can [show the Performance report](#how-browser-performance-testing-works)
+in the merge request widget area.
 
 ## Use cases
 
-For instance, consider the following workflow:
+Consider the following workflow:
 
 1. A member of the marketing team is attempting to track engagement by adding a new tool.
 1. With browser performance metrics, they see how their changes are impacting the usability
    of the page for end users.
-1. The metrics show that after their changes the performance score of the page has gone down.
-1. When looking at the detailed report, they see that the new JavaScript library was
-   included in `<head>` which affects loading page speed.
-1. They ask a front end developer to help them, who sets the library to load asynchronously.
-1. The frontend developer approves the merge request and authorizes its deployment to production.
-
-## How it works
+1. The metrics show that after their changes, the performance score of the page has gone down.
+1. When looking at the detailed report, they see the new JavaScript library was
+   included in `<head>`, which affects loading page speed.
+1. They ask for help from a front end developer, who sets the library to load asynchronously.
+1. The frontend developer approves the merge request, and authorizes its deployment to production.
 
-First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
-[Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance-premium).
-For more information on how the Performance job should look like, check the
-example on [Configuring Browser Performance Testing](#configuring-browser-performance-testing).
+## How browser performance testing works
 
+First, define a job in your `.gitlab-ci.yml` file that generates the
+[Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium).
 GitLab then checks this report, compares key performance metrics for each page
-between the source and target branches, and shows the information right on the merge request.
+between the source and target branches, and shows the information in the merge request.
+
+For an example Performance job, see
+[Configuring Browser Performance Testing](#configuring-browser-performance-testing).
 
 NOTE: **Note:**
-If the Performance report doesn't have anything to compare to, no information
-will be displayed in the merge request area. That is the case when you add the
-Performance job in your `.gitlab-ci.yml` for the very first time.
-Consecutive merge requests will have something to compare to, and the Performance
-report will be shown properly.
+If the Performance report has no data to compare, such as when you add the
+Performance job in your `.gitlab-ci.yml` for the very first time, no information
+displays in the merge request widget area. Consecutive merge requests will have data for
+comparison, and the Performance report will be shown properly.
 
 ![Performance Widget](img/browser_performance_testing.png)
 
@@ -64,52 +59,51 @@ This example shows how to run the [sitespeed.io container](https://hub.docker.co
 on your code by using GitLab CI/CD and [sitespeed.io](https://www.sitespeed.io)
 using Docker-in-Docker.
 
-First, you need GitLab Runner with
-[docker-in-docker build](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
+1. First, set up GitLab Runner with a
+   [docker-in-docker build](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
+1. After configuring the Runner, add a new job to `.gitlab-ci.yml` that generates
+   the expected report.
+1. Define the `performance` job according to your version of GitLab:
 
-Once you set up the Runner, add a new job to `.gitlab-ci.yml` that generates the
-expected report.
+   - For GitLab 12.4 and later - [include](../../../ci/yaml/README.md#includetemplate) the
+     [`Browser-Performance.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml) provided as a part of your GitLab installation.
+   - For GitLab versions earlier than 12.4 - Copy and use the job as defined in the
+     [`Browser-Performance.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml).
 
-For GitLab 12.4 and later, to define the `performance` job, you must
-[include](../../../ci/yaml/README.md#includetemplate) the
-[`Browser-Performance.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml)
-that's provided as a part of your GitLab installation.
-For GitLab versions earlier than 12.4, you can copy and use the job as defined
-in that template.
+   CAUTION: **Caution:**
+   The job definition provided by the template does not support Kubernetes yet.
+   For a complete example of a more complex setup that works in Kubernetes, see
+   [`Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml).
 
-CAUTION: **Caution:**
-The job definition provided by the template does not support Kubernetes yet. For a complete example of a more complex setup
-that works in Kubernetes, see [here](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml).
+1. Add the following to your `.gitlab-ci.yml` file:
 
-Add the following to your `.gitlab-ci.yml` file:
+   ```yaml
+   include:
+     template: Verify/Browser-Performance.gitlab-ci.yml
 
-```yaml
-include:
-  template: Verify/Browser-Performance.gitlab-ci.yml
+   performance:
+     variables:
+       URL: https://example.com
+   ```
 
-performance:
-  variables:
-    URL: https://example.com
-```
-
-CAUTION: **Caution:**
-The job definition provided by the template is supported in GitLab 11.5 and later versions.
-It also requires GitLab Runner 11.5 or later. For earlier versions, use the
-[previous job definitions](#previous-job-definitions).
+   CAUTION: **Caution:**
+   The job definition provided by the template is supported in GitLab 11.5 and later versions.
+   It also requires GitLab Runner 11.5 or later. For earlier versions, use the
+   [previous job definitions](#previous-job-definitions).
 
-The above example will create a `performance` job in your CI/CD pipeline and will run
+The above example creates a `performance` job in your CI/CD pipeline and runs
 sitespeed.io against the webpage you defined in `URL` to gather key metrics.
 The [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance)
-is downloaded in order to save the report as a [Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance-premium)
-that you can later download and analyze. Due to implementation limitations we always
+is downloaded to save the report as a [Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium)
+that you can later download and analyze. Due to implementation limitations, we always
 take the latest Performance artifact available.
 
-The full HTML sitespeed.io report will also be saved as an artifact, and if you have
-[GitLab Pages](../pages/index.md) enabled, it can be viewed directly in your browser.
+The full HTML sitespeed.io report is saved as an artifact, and if
+[GitLab Pages](../pages/index.md) is enabled, it can be viewed directly in your browser.
 
-It is also possible to customize options by setting the `SITESPEED_OPTIONS` variable.
-For example, this is how to override the number of runs sitespeed.io
-will make on the given URL:
+You can also customize options by setting the `SITESPEED_OPTIONS` variable.
+For example, you can override the number of runs sitespeed.io
+makes on the given URL:
 
 ```yaml
 include:
@@ -122,27 +116,47 @@ performance:
 ```
 
 For further customization options for sitespeed.io, including the ability to provide a
-list of URLs to test, please see the [Sitespeed.io Configuration](https://www.sitespeed.io/documentation/sitespeed.io/configuration/)
+list of URLs to test, please see the
+[Sitespeed.io Configuration](https://www.sitespeed.io/documentation/sitespeed.io/configuration/)
 documentation.
 
 TIP: **Tip:**
 Key metrics are automatically extracted and shown in the merge request widget.
 
+### Configuring degradation threshold
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/27599) in GitLab 13.0.
+
+You can configure the sensitivity of degradation alerts to avoid getting alerts for minor drops in metrics.
+This is done by setting the `DEGRADATION_THRESHOLD` variable. In the example below, the alert will only show up
+if the `Total Score` metric degrades by 5 points or more:
+
+```yaml
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
+performance:
+  variables:
+    URL: https://example.com
+    DEGRADATION_THRESHOLD: 5
+```
+
+The `Total Score` metric is based on sitespeed.io's [coach performance score](https://www.sitespeed.io/documentation/sitespeed.io/metrics/#performance-score). There is more information in [the coach documentation](https://www.sitespeed.io/documentation/coach/how-to/#what-do-the-coach-do).
+
 ### Performance testing on Review Apps
 
-The above CI YML is great for testing against static environments, and it can
-be extended for dynamic environments. There are a few extra steps to take to
-set this up:
+The above CI YAML configuration is great for testing against static environments, and it can
+be extended for dynamic environments, but a few extra steps are required:
 
 1. The `performance` job should run after the dynamic environment has started.
 1. In the `review` job, persist the hostname and upload it as an artifact so
-   it's available to the `performance` job (the same can be done for static
-   environments like staging and production to unify the code path). Saving it
-   as an artifact is as simple as `echo $CI_ENVIRONMENT_URL > environment_url.txt`
+   it's available to the `performance` job. The same can be done for static
+   environments like staging and production to unify the code path. You can save it
+   as an artifact with `echo $CI_ENVIRONMENT_URL > environment_url.txt`
    in your job's `script`.
 1. In the `performance` job, read the previous artifact into an environment
-   variable, in this case `$URL` because this is what our sitespeed.io command
-   uses for the URL parameter. Because Review App URLs are dynamic, we define
+   variable. In this case, use `$URL` because the sitespeed.io command
+   uses it for the URL parameter. Because Review App URLs are dynamic, define
    the `URL` variable through `before_script` instead of `variables`.
 1. You can now run the sitespeed.io container against the desired hostname and
    paths.
@@ -183,11 +197,11 @@ performance:
 ### Previous job definitions
 
 CAUTION: **Caution:**
-Before GitLab 11.5, Performance job and artifact had to be named specifically
+Before GitLab 11.5, the Performance job and artifact had to be named specifically
 to automatically extract report data and show it in the merge request widget.
-While these old job definitions are still maintained they have been deprecated
+While these old job definitions are still maintained, they have been deprecated
 and may be removed in next major release, GitLab 12.0.
-You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
+GitLab recommends you update your current `.gitlab-ci.yml` configuration to reflect that change.
 
 For GitLab 11.4 and earlier, the job should look like:
 
diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md
index a7e712a4c0a..beb90e30906 100644
--- a/doc/user/project/merge_requests/code_quality.md
+++ b/doc/user/project/merge_requests/code_quality.md
@@ -27,7 +27,19 @@ in the merge request widget area:
 
 ![Code Quality Widget](img/code_quality.png)
 
-For more information, see the Code Climate list of [Supported Languages for Maintainability](https://docs.codeclimate.com/docs/supported-languages-for-maintainability).
+Watch a quick walkthrough of Code Quality in action:
+
+<div class="video-fallback">
+  See the video: <a href="https://www.youtube.com/watch?v=B32LxtJKo9M">Code Quality: Speed Run</a>.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube.com/embed/B32LxtJKo9M" frameborder="0" allowfullscreen="true"> </iframe>
+</figure>
+
+NOTE: **Note:**
+For one customer, the auditor found that having Code Quality, SAST, and Container Scanning all automated in GitLab CI/CD was almost better than a manual review! [Read more](https://about.gitlab.com/customers/bi_worldwide/).
+
+See also the Code Climate list of [Supported Languages for Maintainability](https://docs.codeclimate.com/docs/supported-languages-for-maintainability).
 
 ## Use cases
 
@@ -37,7 +49,7 @@ For instance, consider the following workflow:
    feature in your app faster.
 1. With Code Quality reports, they analyze how their implementation is impacting
    the code quality.
-1. The metrics show that their code degrade the quality in 10 points.
+1. The metrics show that their code degrades the quality by 10 points.
 1. You ask a co-worker to help them with this modification.
 1. They both work on the changes until Code Quality report displays no
    degradations, only improvements.
@@ -53,10 +65,10 @@ also requires the GitLab Runner 11.5 or later. For earlier versions, use the
 
 This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
 
-First, you need GitLab Runner with:
+First, you need GitLab Runner configured:
 
-- The [docker-in-docker executor](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
-- Enough disk space to handle generated Code Quality files. For example on the [GitLab project](https://gitlab.com/gitlab-org/gitlab) the files are approximately 7 GB.
+- For the [docker-in-docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
+- With enough disk space to handle generated Code Quality files. For example on the [GitLab project](https://gitlab.com/gitlab-org/gitlab) the files are approximately 7 GB.
 
 Once you set up the Runner, include the CodeQuality template in your CI config:
 
@@ -67,7 +79,7 @@ include:
 
 The above example will create a `code_quality` job in your CI/CD pipeline which
 will scan your source code for code quality issues. The report will be saved as a
-[Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality-starter)
+[Code Quality report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality-starter)
 that you can later download and analyze. Due to implementation limitations we always
 take the latest Code Quality artifact available.
 
@@ -227,7 +239,7 @@ do this:
 
 1. Define a job in your `.gitlab-ci.yml` file that generates the
    [Code Quality report
-   artifact](../../../ci/yaml/README.md#artifactsreportscodequality-starter).
+   artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality-starter).
 1. Configure your tool to generate the Code Quality report artifact as a JSON
    file that implements subset of the [Code Climate
    spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types).
diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md
index d8a2b427288..544727380e7 100644
--- a/doc/user/project/merge_requests/creating_merge_requests.md
+++ b/doc/user/project/merge_requests/creating_merge_requests.md
@@ -171,7 +171,7 @@ When the changes are merged, your changes are added to the upstream repository a
 the branch as per specification. After your work is merged, if you don't intend to
 make any other contributions to the upstream project, you can unlink your
 fork from its upstream project in the **Settings > Advanced Settings** section by
-[removing the forking relashionship](../settings/index.md#removing-a-fork-relationship).
+[removing the forking relationship](../settings/index.md#removing-a-fork-relationship).
 
 For further details, [see the forking workflow documentation](../repository/forking_workflow.md).
 
diff --git a/doc/user/project/merge_requests/img/accessibility_mr_widget_v13_0.png b/doc/user/project/merge_requests/img/accessibility_mr_widget_v13_0.png
new file mode 100644
index 00000000000..c52bf9964f1
--- /dev/null
+++ b/doc/user/project/merge_requests/img/accessibility_mr_widget_v13_0.png
diff --git a/doc/user/project/merge_requests/img/code_quality.png b/doc/user/project/merge_requests/img/code_quality.png
index a20f6476fb8..3c6c92baad2 100644
--- a/doc/user/project/merge_requests/img/code_quality.png
+++ b/doc/user/project/merge_requests/img/code_quality.png
diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
index bb5aadfa9b9..fdcb1049ef7 100644
--- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
+++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
@@ -64,6 +64,15 @@ list.
 
 ![Merge request diff file navigation](img/merge_request_diff_file_navigation.png)
 
+### Merge requests commit navigation
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18140) in GitLab 13.0.
+
+To seamlessly navigate among commits in a merge request, from the **Commits** tab, click one of
+the commits to open the single-commit view. From there, you can navigate among the commits
+by clicking the **Prev** and **Next** buttons on the top-right of the page or by using the
+<kbd>X</kbd> and <kbd>C</kbd> keyboard shortcuts.
+
 ### Incrementally expand merge request diffs
 
 By default, the diff shows only the parts of a file which are changed.
@@ -102,7 +111,7 @@ you will be able to see:
 - Both pre and post-merge pipelines and the environment information if any.
 - Which deployments are in progress.
 
-If there's an [environment](../../../ci/environments.md) and the application is
+If there's an [environment](../../../ci/environments/index.md) and the application is
 successfully deployed to it, the deployed environment and the link to the
 Review App will be shown as well.
 
diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md
index 71fbdaf112f..84d60fca72d 100644
--- a/doc/user/project/merge_requests/test_coverage_visualization.md
+++ b/doc/user/project/merge_requests/test_coverage_visualization.md
@@ -17,14 +17,14 @@ MR is merged.
 ## How test coverage visualization works
 
 Collecting the coverage information is done via GitLab CI/CD's
-[artifacts reports feature](../../../ci/yaml/README.md#artifactsreports).
+[artifacts reports feature](../../../ci/pipelines/job_artifacts.md#artifactsreports).
 You can specify one or more coverage reports to collect, including wildcard paths.
 GitLab will then take the coverage information in all the files and combine it
 together.
 
 For the coverage analysis to work, you have to provide a properly formatted
 [Cobertura XML](https://cobertura.github.io/cobertura/) report to
-[`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura).
+[`artifacts:reports:cobertura`](../../../ci/pipelines/job_artifacts.md#artifactsreportscobertura).
 This format was originally developed for Java, but most coverage analysis frameworks
 for other languages have plugins to add support for it, like:
 
diff --git a/doc/user/project/merge_requests/versions.md b/doc/user/project/merge_requests/versions.md
index 2f51af24a95..84934148bdc 100644
--- a/doc/user/project/merge_requests/versions.md
+++ b/doc/user/project/merge_requests/versions.md
@@ -57,7 +57,7 @@ source and target branch can be shown mixed together making it hard to
 understand which changes are being added and which already exist in the
 target branch.
 
-In GitLab 12.10, we added an **experimental** comparison mode, which
+In GitLab 12.10, we added a comparison mode, which
 shows a diff calculated by simulating how it would look like once merged - a more accurate
 representation of the changes rather than using the base of the two
 branches. The new mode is available from the comparison target drop down
@@ -67,26 +67,6 @@ current default comparison.
 
 ![Merge request versions compare HEAD](img/versions_compare_head_v12_10.png)
 
-### Enable or disable `HEAD` comparison mode **(CORE ONLY)**
-
-`HEAD` comparison mode is under development and not ready for production use. It is
-deployed behind a feature flag that is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/troubleshooting/navigating_gitlab_via_rails_console.md#starting-a-rails-console-session)
-can enable it for your instance. You're welcome to test it, but use it at your
-own risk.
-
-To enable it:
-
-```ruby
-Feature.enable(:diff_compare_with_head)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:diff_compare_with_head)
-```
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues