Add latest changes from gitlab-org/gitlab@12-6-stable-ee

117 files changed, 1454 insertions, 373 deletions

diff --git a/doc/user/admin_area/appearance.md b/doc/user/admin_area/appearance.md
index 1fea6ab8b02..b9eb9e2a731 100644
--- a/doc/user/admin_area/appearance.md
+++ b/doc/user/admin_area/appearance.md
@@ -46,8 +46,8 @@ of your GitLab instance. These messages will appear on all projects and pages of
 instance, including the sign in / sign up page. The default color is white text on
 an orange background, but this can be customized by clicking on **Customize colors**.
 
-Limited [markdown](../markdown.md) is supported, such as bold, italics, and links, for
-example. Other markdown features, including lists, images and quotes, are not supported,
+Limited [Markdown](../markdown.md) is supported, such as bold, italics, and links, for
+example. Other Markdown features, including lists, images and quotes, are not supported,
 as the header and footer messages can only be a single line.
 
 ![header and footer screenshot](img/appearance_header_footer_v12_3.png)
@@ -61,7 +61,7 @@ to activate it in the GitLab instance.
 ## Sign in / Sign up pages
 
 You can replace the default message on the sign in / sign up page with your own message
-and logo. You can make full use of [markdown](../markdown.md) in the description:
+and logo. You can make full use of [Markdown](../markdown.md) in the description:
 
 ![sign in message screenshot](img/appearance_sign_in_v12_3.png)
 
@@ -81,7 +81,7 @@ You can add also add a [customized help message](settings/help_page.md) below th
 ## New project pages
 
 You can add a new project guidelines message to the **New project page** within GitLab.
-You can make full use of [markdown](../markdown.md) in the description:
+You can make full use of [Markdown](../markdown.md) in the description:
 
 ![new project message screenshot](img/appearance_new_project_v12_3.png)
 
diff --git a/doc/user/admin_area/broadcast_messages.md b/doc/user/admin_area/broadcast_messages.md
index b0491499f88..bc51552603d 100644
--- a/doc/user/admin_area/broadcast_messages.md
+++ b/doc/user/admin_area/broadcast_messages.md
@@ -22,6 +22,7 @@ To add a broadcast message:
 1. Navigate to the **Admin Area > Messages** page.
 1. Add the text for the message to the **Message** field. Markdown and emoji are supported.
 1. If required, click the **Customize colors** link to edit the background color and font color of the message.
+1. If required, add a **Target Path** to only show the broadcast message on URLs matching that path. You can use the wildcard character `*` to match multiple URLs, for example `/users/*/issues`.
 1. Select a date for the message to start and end.
 1. Click the **Add broadcast message** button.
 
diff --git a/doc/user/admin_area/credentials_inventory.md b/doc/user/admin_area/credentials_inventory.md
new file mode 100644
index 00000000000..30ebbb5b6db
--- /dev/null
+++ b/doc/user/admin_area/credentials_inventory.md
@@ -0,0 +1,19 @@
+# Credentials inventory **(ULTIMATE ONLY)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/20912) in GitLab 12.6.
+
+## Overview
+
+GitLab administrators are responsible for the overall security of their instance. To assist, GitLab provides a Credentials inventory to keep track of all the credentials that can be used to access their self-managed instance.
+
+Using Credentials inventory, GitLab administrators can see all the personal access tokens and SSH keys that exist in their instance and:
+
+- Who they belong to.
+- Their access scope.
+- Their usage pattern.
+
+To access the Credentials inventory, navigate to **Admin Area > Credentials**.
+
+The following is an example of the Credentials inventory page:
+
+![Credentials inventory page](img/credentials_inventory_v12_6.png)
diff --git a/doc/user/admin_area/img/credentials_inventory_v12_6.png b/doc/user/admin_area/img/credentials_inventory_v12_6.png
new file mode 100644
index 00000000000..ff46db61cdb
--- /dev/null
+++ b/doc/user/admin_area/img/credentials_inventory_v12_6.png
diff --git a/doc/user/admin_area/img/minimum_password_length_settings_v12_6.png b/doc/user/admin_area/img/minimum_password_length_settings_v12_6.png
new file mode 100644
index 00000000000..f75d9e9bb29
--- /dev/null
+++ b/doc/user/admin_area/img/minimum_password_length_settings_v12_6.png
diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md
index dbcf250bc57..fe8903a9f01 100644
--- a/doc/user/admin_area/license.md
+++ b/doc/user/admin_area/license.md
@@ -67,7 +67,7 @@ Omnibus installations should add this entry to `gitlab.rb`:
 gitlab_rails['license_file'] = "/path/to/license/file"
 ```
 
-CAUTION:: **Caution:**
+CAUTION: **Caution:**
 These methods will only add a license at the time of installation. Use the
 admin area in the web ui to renew or upgrade licenses.
 
diff --git a/doc/user/admin_area/monitoring/convdev.md b/doc/user/admin_area/monitoring/convdev.md
deleted file mode 100644
index 6ad8a5a7ff0..00000000000
--- a/doc/user/admin_area/monitoring/convdev.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-redirect_to: '../../instance_statistics/convdev.md'
----
-
-This document was moved to [another location](../../instance_statistics/convdev.md).
diff --git a/doc/user/admin_area/monitoring/dev_ops_score.md b/doc/user/admin_area/monitoring/dev_ops_score.md
new file mode 100644
index 00000000000..f8b66531f2f
--- /dev/null
+++ b/doc/user/admin_area/monitoring/dev_ops_score.md
@@ -0,0 +1,5 @@
+---
+redirect_to: '../../instance_statistics/dev_ops_score.md'
+---
+
+This document was moved to [another location](../../instance_statistics/dev_ops_score.md).
diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md
index 103d7ecc573..68767efc72a 100644
--- a/doc/user/admin_area/monitoring/health_check.md
+++ b/doc/user/admin_area/monitoring/health_check.md
@@ -103,7 +103,7 @@ This check is being exempt from Rack Attack.
 ## Liveness
 
 DANGER: **Warning:**
-In Gitlab [12.4](https://about.gitlab.com/upcoming-releases/)
+In GitLab [12.4](https://about.gitlab.com/upcoming-releases/)
 the response body of the Liveness check was changed
 to match the example below.
 
diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md
index e443127a8a0..9d82b3b4292 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -84,3 +84,35 @@ add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachme
 ```
 nginx['client_max_body_size'] = "200m"
 ```
+
+## Limiting lifetime of personal access tokens **(ULTIMATE ONLY)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3649) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6.
+
+Users can optionally specify an expiration date for
+[personal access tokens](../../profile/personal_access_tokens.md).
+This expiration date is not a requirement, and can be set to any arbitrary date.
+
+Since personal access tokens are the only token needed for programmatic access to GitLab,
+organizations with security requirements may want to enforce more protection to require
+regular rotation of these tokens.
+
+### Setting a limit
+
+Only a GitLab administrator can set a limit. Leaving it empty means
+there are no restrictions.
+
+To set a limit on how long personal access tokens are valid:
+
+1. Navigate to **Admin Area > Settings > General**.
+1. Expand the **Account and limit** section.
+1. Fill in the **Maximun allowable lifetime for personal access tokens (days)** field.
+1. Click **Save changes**.
+
+Once a lifetime for personal access tokens is set, GitLab will:
+
+- Apply the lifetime for new personal access tokens, and require users to set an expiration date
+  and a date no later than the allowed lifetime.
+- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the
+  allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
+  or remove it, before revocation takes place.
diff --git a/doc/user/admin_area/settings/protected_paths.md b/doc/user/admin_area/settings/protected_paths.md
index 21c8d79b138..5d2548890e3 100644
--- a/doc/user/admin_area/settings/protected_paths.md
+++ b/doc/user/admin_area/settings/protected_paths.md
@@ -14,7 +14,8 @@ GitLab protects the following paths with Rack Attack by default:
 '/users',
 '/users/confirmation',
 '/unsubscribes/',
-'/import/github/personal_access_token'
+'/import/github/personal_access_token',
+'/admin/session'
 ```
 
 GitLab responds with HTTP status code `429` to POST requests at protected paths
@@ -59,18 +60,14 @@ NOTE: **Note:** If Omnibus settings are present, applications settings will be a
 
 To migrate from Omnibus GitLab 12.3 and earlier settings:
 
-1. Disable the Protected Paths throttle from Omnibus, by changing `rack_attack_enabled` value to `false` on [`rack_attack.rb.erb`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/rack_attack.rb.erb#L18):
-
-   ```ruby
-   rack_attack_enabled = false
-   ```
-
 1. Customize and enable your protected paths settings by following [Configure using GitLab UI](#configure-using-gitlab-ui) section.
 
-1. Restart GitLab:
+1. SSH into your frontend nodes and add to `/etc/gitlab/gitlab.rb`:
 
-   ```bash
-   sudo gitlab-ctl restart
+   ```ruby
+   gitlab_rails['rack_attack_admin_area_protected_paths_enabled'] = true
    ```
 
+1. [Reconfigure GitLab](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 That's it. Protected paths throttle are now managed by GitLab admin settings.
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index ff26a1ee09c..851a984c285 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -19,6 +19,13 @@ their email address before they are allowed to sign in.
 
 ![Email confirmation](img/email_confirmation.png)
 
+## Minimum password length limit
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/20661) in GitLab 12.6
+
+You can [change](../../../security/password_length_limits.md#modify-minimum-password-length-using-gitlab-ui)
+the minimum number of characters a user must have in their password using the GitLab UI.
+
 ## Whitelist email domains
 
 > [Introduced][ce-598] in GitLab 7.11.0
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
index 73406fd5037..74398128593 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -14,8 +14,11 @@ To access the visibility and access control options:
 
 ## Default branch protection
 
-Branch protection specifies which roles can push to branches and which roles can delete
-branches.
+This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
+branches.  In this case _Default_ refers to a repository's default branch, which in most cases is _master_.
+branches.  "Default" in this case refers to a repository's default branch, which in most cases would be "master".
+
+This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md).
 
 To change the default branch protection:
 
@@ -35,7 +38,7 @@ To change the default project creation protection:
 
 For more details, see [Default project-creation level](../../group/index.md#default-project-creation-level).
 
-## Default project deletion protection
+## Default project deletion protection **(PREMIUM ONLY)**
 
 By default, a project can be deleted by anyone with the **Owner** role, either at the project or
 group level.
@@ -45,6 +48,17 @@ To ensure only admin users can delete projects:
 1. Check the **Default project deletion protection** checkbox.
 1. Click **Save changes**.
 
+## Project deletion adjourned period **(PREMIUM ONLY)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/32935) in GitLab 12.6.
+
+By default, project marked for deletion will be permanently removed after 7 days. This period may be changed.
+
+To change this period:
+
+1. Select the desired option.
+1. Click **Save changes**.
+
 ## Default project visibility
 
 To set the default visibility levels for new projects:
diff --git a/doc/user/analytics/cycle_analytics.md b/doc/user/analytics/cycle_analytics.md
index c75f101b0e1..796cae70803 100644
--- a/doc/user/analytics/cycle_analytics.md
+++ b/doc/user/analytics/cycle_analytics.md
@@ -153,6 +153,27 @@ A few notes:
   cycles, calculate their median time and the result is what the dashboard of
   Cycle Analytics is showing.
 
+## Days to completion chart
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/21631) in GitLab 12.6.
+
+This chart visually depicts the total number of days it takes for cycles to be completed.
+
+This chart uses the global page filters for displaying data based on the selected
+group, projects, and timeframe. In addition, specific stages can be selected
+from within the chart itself.
+
+### Enabling chart
+
+By default, this chart is disabled for self-managed instances. To enable it, ask an
+administrator with Rails console access to run the following:
+
+```ruby
+Feature.enable(:cycle_analytics_scatterplot_enabled)
+```
+
+This chart is enabled by default on GitLab.com.
+
 ## Permissions
 
 The current permissions on the Project Cycle Analytics dashboard are:
diff --git a/doc/user/application_security/configuration/index.md b/doc/user/application_security/configuration/index.md
new file mode 100644
index 00000000000..c8d7edff2d6
--- /dev/null
+++ b/doc/user/application_security/configuration/index.md
@@ -0,0 +1,27 @@
+---
+type: reference, howto
+---
+
+# Security Configuration **(ULTIMATE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/20711) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6.
+
+## Overview
+
+The security configuration page displays the configuration state of each of the security
+features and can be accessed through a project's sidebar nav.
+
+![Screenshot of security configuration page](../img/security_configuration_page_v12_6.png)
+
+The page uses the project's latest default branch [CI pipeline](../../../ci/pipelines.md) to determine the configuration
+state of each feature. If a job with the expected security report artifact exists in the pipeline,
+the feature is considered configured.
+
+NOTE: **Note:** if the latest pipeline used [Auto DevOps](../../../topics/autodevops/index.md),
+all security features will be configured by default.
+
+## Limitations
+
+It is not possible to enable or disable a feature using the configuration page.
+However, instructions on how to enable or disable a feature can be found through
+the links next to each feature on that page.
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 931755c6305..08242b3c65b 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -127,7 +127,7 @@ If you want to whitelist specific vulnerabilities, you'll need to:
    [overriding the Container Scanning template](#overriding-the-container-scanning-template) section of this document.
    1. Define the whitelisted vulnerabilities in a YAML file named `clair-whitelist.yml` which must use the format described
    in the [following whitelist example file](https://github.com/arminc/clair-scanner/blob/v12/example-whitelist.yaml).
-   1. Add the `clair-whitelist.yml` file to the git repository of your project
+   1. Add the `clair-whitelist.yml` file to the Git repository of your project
 
 ### Overriding the Container Scanning template
 
@@ -219,6 +219,94 @@ build_latest_vulnerabilities:
 
 The above template will work for a GitLab Docker registry running on a local installation, however, if you're using a non-GitLab Docker registry, you'll need to change the `$CI_REGISTRY` value and the `docker login` credentials to match the details of your local registry.
 
+## Reports JSON format
+
+CAUTION: **Caution:**
+The JSON report artifacts are not a public API of Container Scanning and their format may change in the future.
+
+The Container Scanning tool emits a JSON report file. Here is an example of the report structure with all important parts of
+it highlighted:
+
+```json-doc
+{
+  "version": "2.3",
+  "vulnerabilities": [
+    {
+      "category": "container_scanning",
+      "message": "CVE-2019-3462 in apt",
+      "description": "Incorrect sanitation of the 302 redirect field in HTTP transport method of apt versions 1.4.8 and earlier can lead to content injection by a MITM attacker, potentially leading to remote code execution on the target machine.",
+      "cve": "debian:9:apt:CVE-2019-3462",
+      "severity": "High",
+      "confidence": "Unknown",
+      "solution": "Upgrade apt from 1.4.8 to 1.4.9",
+      "scanner": {
+        "id": "klar",
+        "name": "klar"
+      },
+      "location": {
+        "dependency": {
+          "package": {
+            "name": "apt"
+          },
+          "version": "1.4.8"
+        },
+        "operating_system": "debian:9",
+        "image": "registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256:bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e"
+      },
+      "identifiers": [
+        {
+          "type": "cve",
+          "name": "CVE-2019-3462",
+          "value": "CVE-2019-3462",
+          "url": "https://security-tracker.debian.org/tracker/CVE-2019-3462"
+        }
+      ],
+      "links": [
+        {
+          "url": "https://security-tracker.debian.org/tracker/CVE-2019-3462"
+        }
+      ]
+    }
+  ],
+  "remediations": [
+  ]
+}
+```
+
+Here is the description of the report file structure nodes and their meaning. All fields are mandatory to be present in
+the report JSON unless stated otherwise. Presence of optional fields depends on the underlying analyzers being used.
+
+| Report JSON node                                     | Description                                                                                                                                                                                                                                                                                                                                                                                |
+|------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `version`                                            | Report syntax version used to generate this JSON.                                                                                                                                                                                                                                                                                                                                          |
+| `vulnerabilities`                                    | Array of vulnerability objects.                                                                                                                                                                                                                                                                                                                                                            |
+| `vulnerabilities[].category`                         | Where this vulnerability belongs (SAST, Container Scanning etc.). For Container Scanning, it will always be `container_scanning`.                                                                                                                                                                                                                                                          |
+| `vulnerabilities[].message`                          | A short text that describes the vulnerability, it may include occurrence's specific information. Optional.                                                                                                                                                                                                                                                                                 |
+| `vulnerabilities[].description`                      | A long text that describes the vulnerability. Optional.                                                                                                                                                                                                                                                                                                                                    |
+| `vulnerabilities[].cve`                              | A fingerprint string value that represents a concrete occurrence of the vulnerability. It's used to determine whether two vulnerability occurrences are same or different. May not be 100% accurate. **This is NOT a [CVE](https://cve.mitre.org/)**.                                                                                                                                      |
+| `vulnerabilities[].severity`                         | How much the vulnerability impacts the software. Possible values: `Undefined` (an analyzer has not provided this info), `Info`, `Unknown`, `Low`, `Medium`, `High`, `Critical`.  **Note:** Our current container scanning tool based on [klar](https://github.com/optiopay/klar) only provides the following levels: `Unknown`, `Low`, `Medium`, `High`, `Critical`.                       |
+| `vulnerabilities[].confidence`                       | How reliable the vulnerability's assessment is. Possible values: `Undefined` (an analyzer has not provided this info), `Ignore`, `Unknown`, `Experimental`, `Low`, `Medium`, `High`, `Confirmed`.  **Note:** Our current container scanning tool based on [klar](https://github.com/optiopay/klar) does not provide a confidence level, so this value is currently hardcoded to `Unknown`. |
+| `vulnerabilities[].solution`                         | Explanation of how to fix the vulnerability. Optional.                                                                                                                                                                                                                                                                                                                                     |
+| `vulnerabilities[].scanner`                          | A node that describes the analyzer used to find this vulnerability.                                                                                                                                                                                                                                                                                                                        |
+| `vulnerabilities[].scanner.id`                       | Id of the scanner as a snake_case string.                                                                                                                                                                                                                                                                                                                                                  |
+| `vulnerabilities[].scanner.name`                     | Name of the scanner, for display purposes.                                                                                                                                                                                                                                                                                                                                                 |
+| `vulnerabilities[].location`                         | A node that tells where the vulnerability is located.                                                                                                                                                                                                                                                                                                                                      |
+| `vulnerabilities[].location.dependency`              | A node that describes the dependency of a project where the vulnerability is located.                                                                                                                                                                                                                                                                                                      |
+| `vulnerabilities[].location.dependency.package`      | A node that provides the information on the package where the vulnerability is located.                                                                                                                                                                                                                                                                                                    |
+| `vulnerabilities[].location.dependency.package.name` | Name of the package where the vulnerability is located.                                                                                                                                                                                                                                                                                                                                    |
+| `vulnerabilities[].location.dependency.version`      | Version of the vulnerable package. Optional.                                                                                                                                                                                                                                                                                                                                               |
+| `vulnerabilities[].location.operating_system`        | The operating system that contains the vulnerable package.                                                                                                                                                                                                                                                                                                                                 |
+| `vulnerabilities[].location.image`                   | The Docker image that was analyzed. Optional.                                                                                                                                                                                                                                                                                                                                              |
+| `vulnerabilities[].identifiers`                      | An ordered array of references that identify a vulnerability on internal or external DBs.                                                                                                                                                                                                                                                                                                  |
+| `vulnerabilities[].identifiers[].type`               | Type of the identifier. Possible values: common identifier types (among `cve`, `cwe`, `osvdb`, and `usn`).                                                                                                                                                                                                                                                                                 |
+| `vulnerabilities[].identifiers[].name`               | Name of the identifier for display purpose.                                                                                                                                                                                                                                                                                                                                                |
+| `vulnerabilities[].identifiers[].value`              | Value of the identifier for matching purpose.                                                                                                                                                                                                                                                                                                                                              |
+| `vulnerabilities[].identifiers[].url`                | URL to identifier's documentation. Optional.                                                                                                                                                                                                                                                                                                                                               |
+| `vulnerabilities[].links`                            | An array of references to external documentation pieces or articles that describe the vulnerability further. Optional.                                                                                                                                                                                                                                                                     |
+| `vulnerabilities[].links[].name`                     | Name of the vulnerability details link. Optional.                                                                                                                                                                                                                                                                                                                                          |
+| `vulnerabilities[].links[].url`                      | URL of the vulnerability details document. Optional.                                                                                                                                                                                                                                                                                                                                       |
+| `remediations`                                       | Not supported yet.                                                                                                                                                                                                                                                                                                                                                                         |
+
 ## Troubleshooting
 
 ### docker: Error response from daemon: failed to copy xattrs
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index d285b5ff585..3a8a81f5f57 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -85,7 +85,7 @@ There are two ways to define the URL to be scanned by DAST:
 
 1. Add it in an `environment_url.txt` file at the root of your project.
     This is great for testing in dynamic environments. In order to run DAST against
-    an app that is dynamically created during a Gitlab CI pipeline, have the app
+    an app that is dynamically created during a GitLab CI pipeline, have the app
     persist its domain in an `environment_url.txt` file, and DAST will
     automatically parse that file to find its scan target.
     You can see an [example](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
@@ -228,7 +228,7 @@ server {
 ###### Apache
 
 Apache can also be used as a [reverse proxy](https://httpd.apache.org/docs/2.4/mod/mod_proxy.html)
-to add the Gitlab-DAST-Permission [header](https://httpd.apache.org/docs/current/mod/mod_headers.html).
+to add the `Gitlab-DAST-Permission` [header](https://httpd.apache.org/docs/current/mod/mod_headers.html).
 
 To do so, add the following lines to `httpd.conf`:
 
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 0e46052b0bd..01feaaac423 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -55,7 +55,7 @@ The following languages and dependency managers are supported.
 
 | Language (package managers)  | Supported | Scan tool(s) |
 |----------------------------- | --------- | ------------ |
-| Java ([Gradle](https://gradle.org/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/13075 "Dependency Scanning for Gradle" )) | not available |
+| Java ([Gradle](https://gradle.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
 | Java ([Maven](https://maven.apache.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
 | JavaScript ([npm](https://www.npmjs.com/), [yarn](https://yarnpkg.com/en/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium), [Retire.js](https://retirejs.github.io/retire.js/)         |
 | Go ([Golang](https://golang.org/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/7132 "Dependency Scanning for Go")) | not available |
@@ -64,6 +64,7 @@ The following languages and dependency managers are supported.
 | Python ([Pipfile](https://pipenv.kennethreitz.org/en/latest/basics/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/11756 "Pipfile.lock support for Dependency Scanning"))| not available |
 | Python ([poetry](https://poetry.eustace.io/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/7006 "Support Poetry in Dependency Scanning")) | not available |
 | Ruby ([gem](https://rubygems.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium), [bundler-audit](https://github.com/rubysec/bundler-audit) |
+| Scala ([sbt](https://www.scala-sbt.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
 
 ## Configuration
 
@@ -127,23 +128,26 @@ dependency_scanning:
 Dependency Scanning can be [configured](#customizing-the-dependency-scanning-settings)
 using environment variables.
 
-| Environment variable                    | Description | Example usage |
-| --------------------------------------- | ----------- | ------------- |
-| `DS_ANALYZER_IMAGES`                    | Comma separated list of custom images. The official default images are still enabled. Read more about [customizing analyzers](analyzers.md). | |
-| `DS_ANALYZER_IMAGE_PREFIX`              | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). | |
-| `DS_ANALYZER_IMAGE_TAG`                 | Override the Docker tag of the official default images. Read more about [customizing analyzers](analyzers.md). | |
-| `DS_PYTHON_VERSION`                     | Version of Python. If set to 2, dependencies are installed using Python 2.7 instead of Python 3.6. ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12296) in GitLab 12.1)| |
-| `DS_PIP_DEPENDENCY_PATH`                | Path to load Python pip dependencies from. ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12412) in GitLab 12.2) | |
-| `DS_DEFAULT_ANALYZERS`                  | Override the names of the official default images. Read more about [customizing analyzers](analyzers.md). | |
-| `DS_DISABLE_DIND`                       | Disable Docker in Docker and run analyzers [individually](#disabling-docker-in-docker-for-dependency-scanning).| |
-| `DS_PULL_ANALYZER_IMAGES`               | Pull the images from the Docker registry (set to `0` to disable). | |
-| `DS_EXCLUDED_PATHS`                     | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, file or folder paths. Parent directories will also match patterns. | `DS_EXCLUDED_PATHS=doc,spec` |
-| `DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT`  | Time limit for Docker client negotiation. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. | |
-| `DS_PULL_ANALYZER_IMAGE_TIMEOUT`        | Time limit when pulling the image of an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. | |
-| `DS_RUN_ANALYZER_TIMEOUT`               | Time limit when running an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. | |
-| `PIP_INDEX_URL`                         | Base URL of Python Package Index (default `https://pypi.org/simple`). | |
-| `PIP_EXTRA_INDEX_URL`                   | Array of [extra URLs](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-extra-index-url) of package indexes to use in addition to `PIP_INDEX_URL`. Comma separated. | |
-| `MAVEN_CLI_OPTS`                        | List of command line arguments that will be passed to the maven analyzer during the project's build phase (see example for [using private repos](#using-private-maven-repos)). | |
+| Environment variable                    | Description |
+| --------------------------------------- | ----------- |
+| `DS_ANALYZER_IMAGES`                    | Comma separated list of custom images. The official default images are still enabled. Read more about [customizing analyzers](analyzers.md). |
+| `DS_ANALYZER_IMAGE_PREFIX`              | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). |
+| `DS_ANALYZER_IMAGE_TAG`                 | Override the Docker tag of the official default images. Read more about [customizing analyzers](analyzers.md). |
+| `DS_PYTHON_VERSION`                     | Version of Python. If set to 2, dependencies are installed using Python 2.7 instead of Python 3.6. ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12296) in GitLab 12.1)|
+| `DS_PIP_VERSION`                        | Force the install of a specific pip version (example: `"19.3"`), otherwise the pip installed in the docker image is used. |
+| `DS_PIP_DEPENDENCY_PATH`                | Path to load Python pip dependencies from. ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12412) in GitLab 12.2) |
+| `DS_DEFAULT_ANALYZERS`                  | Override the names of the official default images. Read more about [customizing analyzers](analyzers.md). |
+| `DS_DISABLE_DIND`                       | Disable Docker in Docker and run analyzers [individually](#disabling-docker-in-docker-for-dependency-scanning).|
+| `DS_PULL_ANALYZER_IMAGES`               | Pull the images from the Docker registry (set to `0` to disable). |
+| `DS_EXCLUDED_PATHS`                     | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, file or folder paths (e.g., `doc,spec`). Parent directories will also match patterns. |
+| `DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT`  | Time limit for Docker client negotiation. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
+| `DS_PULL_ANALYZER_IMAGE_TIMEOUT`        | Time limit when pulling the image of an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
+| `DS_RUN_ANALYZER_TIMEOUT`               | Time limit when running an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
+| `PIP_INDEX_URL`                         | Base URL of Python Package Index (default `https://pypi.org/simple`). |
+| `PIP_EXTRA_INDEX_URL`                   | Array of [extra URLs](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-extra-index-url) of package indexes to use in addition to `PIP_INDEX_URL`. Comma separated. |
+| `PIP_REQUIREMENTS_FILE`                 | Pip requirements file to be scanned. |
+| `MAVEN_CLI_OPTS`                        | List of command line arguments that will be passed to the maven analyzer during the project's build phase (see example for [using private repos](#using-private-maven-repos)). |
+| `BUNDLER_AUDIT_UPDATE_DISABLED`         | Disable automatic updates for the `bundler-audit` analyzer (default: `"false"`). Useful if you're running Dependency Scanning in an offline, air-gapped environment.|
 
 ### Using private Maven repos
 
diff --git a/doc/user/application_security/img/security_configuration_page_v12_6.png b/doc/user/application_security/img/security_configuration_page_v12_6.png
new file mode 100644
index 00000000000..d838b648c1f
--- /dev/null
+++ b/doc/user/application_security/img/security_configuration_page_v12_6.png
diff --git a/doc/user/application_security/sast/analyzers.md b/doc/user/application_security/sast/analyzers.md
index b79edc9d5a8..a42cf7f09ff 100644
--- a/doc/user/application_security/sast/analyzers.md
+++ b/doc/user/application_security/sast/analyzers.md
@@ -18,10 +18,11 @@ SAST supports the following official analyzers:
 - [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (JavaScript and React))
 - [`flawfinder`](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (Flawfinder)
 - [`gosec`](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) (Gosec)
+- [`kubesec`](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec) (Kubesec)
 - [`nodejs-scan`](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (NodeJsScan)
 - [`phpcs-security-audit`](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) (PHP CS security-audit)
 - [`pmd-apex`](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex) (PMD (Apex only))
-- [`secrets`](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) (Secrets (Gitleaks, TruffleHog & Diffence secret detectors))
+- [`secrets`](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) (Secrets (Gitleaks & TruffleHog secret detectors))
 - [`security-code-scan`](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) (Security Code Scan (.NET))
 - [`sobelow`](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow) (Sobelow (Elixir Phoenix))
 - [`spotbugs`](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) (SpotBugs with the Find Sec Bugs plugin (Ant, Gradle and wrapper, Grails, Maven and wrapper, SBT))
@@ -116,24 +117,24 @@ Custom analyzers are not spawned automatically when [Docker In Docker](index.md#
 
 ## Analyzers Data
 
-| Property \ Tool                         | Apex                 | Bandit               | Brakeman             | ESLint security      | Find Sec Bugs        | Flawfinder           | Go AST Scanner       | NodeJsScan           | Php CS Security Audit   | Security code Scan (.NET)   | TSLint Security    | Sobelow            |
-| --------------------------------------- | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :---------------------: | :-------------------------: | :-------------:    | :----------------: |
-| Severity                                | ✓   | ✓   | 𐄂                  | 𐄂                  | ✓   | 𐄂                  | ✓   | 𐄂                  | ✓      | 𐄂                         | ✓ | 𐄂                |
-| Title                                   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓      | ✓          | ✓ | ✓ |
-| Description                             | ✓   | 𐄂                  | 𐄂                  | ✓   | ✓   | 𐄂                  | 𐄂                  | ✓   | 𐄂                     | 𐄂                         | ✓ | ✓ |
-| File                                    | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓      | ✓          | ✓ | ✓ |
-| Start line                              | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓      | ✓          | ✓ | ✓ |
-| End line                                | ✓   | ✓   | 𐄂                  | ✓   | ✓   | 𐄂                  | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | ✓ | 𐄂                |
-| Start column                            | ✓   | 𐄂                  | 𐄂                  | ✓   | ✓   | ✓   | ✓   | 𐄂                  | ✓      | ✓          | ✓ | 𐄂                |
-| End column                              | ✓   | 𐄂                  | 𐄂                  | ✓   | ✓   | 𐄂                  | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | ✓ | 𐄂                |
-| External id (e.g. CVE)                  | 𐄂   | 𐄂                  | ⚠            | 𐄂                  | ⚠            | ✓   | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | 𐄂                |
-| URLs                                    | ✓   | 𐄂                  | ✓   | 𐄂                  | ⚠            | 𐄂                 | ⚠       | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | 𐄂                |
-| Internal doc/explanation                | ✓   | ⚠            | ✓   | 𐄂                  | ✓   | 𐄂                  | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | ✓ |
-| Solution                                | ✓   | 𐄂                  | 𐄂                  | 𐄂                  | ⚠            | ✓   | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | 𐄂                |
-| Confidence                              | 𐄂   | ✓   | ✓   | 𐄂                  | ✓   | ✓   | ✓   | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | ✓ |
-| Affected item (e.g. class or package)   | ✓   | 𐄂                  | ✓   | 𐄂                  | ✓   | ✓   | 𐄂                  | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | 𐄂                |
-| Source code extract                     | 𐄂   | ✓   | ✓   | ✓   | 𐄂                  | ✓   | ✓   | 𐄂                  | 𐄂                     | 𐄂                         | 𐄂                | 𐄂                |
-| Internal ID                             | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | ✓   | 𐄂                  | ✓      | ✓          | ✓ | ✓ |
+| Property \ Tool                         | Apex                 | Bandit               | Brakeman             | ESLint security      | Find Sec Bugs        | Flawfinder           | Go AST Scanner       | Kubesec Scanner      | NodeJsScan           | Php CS Security Audit   | Security code Scan (.NET)   | Sobelow            | TSLint Security    |
+| --------------------------------------- | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :------------------: | :---------------------: | :-------------------------: | :----------------: | :-------------:    |
+| Severity                                | ✓                    | ✓                    | 𐄂                    | 𐄂                    | ✓                    | 𐄂                    | ✓                    | ✓                    | 𐄂                    | ✓                       | 𐄂                           | 𐄂                  | ✓                  |
+| Title                                   | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                       | ✓                           | ✓                  | ✓                  |
+| Description                             | ✓                    | 𐄂                    | 𐄂                    | ✓                    | ✓                    | 𐄂                    | 𐄂                    | ✓                    | ✓                    | 𐄂                       | 𐄂                           | ✓                  | ✓                  |
+| File                                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                       | ✓                           | ✓                  | ✓                  |
+| Start line                              | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | 𐄂                    | ✓                    | ✓                       | ✓                           | ✓                  | ✓                  |
+| End line                                | ✓                    | ✓                    | 𐄂                    | ✓                    | ✓                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | ✓                  |
+| Start column                            | ✓                    | 𐄂                    | 𐄂                    | ✓                    | ✓                    | ✓                    | ✓                    | 𐄂                    | 𐄂                    | ✓                       | ✓                           | 𐄂                  | ✓                  |
+| End column                              | ✓                    | 𐄂                    | 𐄂                    | ✓                    | ✓                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | ✓                  |
+| External id (e.g. CVE)                  | 𐄂                    | 𐄂                    | ⚠                    | 𐄂                    | ⚠                    | ✓                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | 𐄂                  |
+| URLs                                    | ✓                    | 𐄂                    | ✓                    | 𐄂                    | ⚠                    | 𐄂                    | ⚠                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | 𐄂                  |
+| Internal doc/explanation                | ✓                    | ⚠                    | ✓                    | 𐄂                    | ✓                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | ✓                  | 𐄂                  |
+| Solution                                | ✓                    | 𐄂                    | 𐄂                    | 𐄂                    | ⚠                    | ✓                    | 𐄂                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | 𐄂                  |
+| Affected item (e.g. class or package)   | ✓                    | 𐄂                    | ✓                    | 𐄂                    | ✓                    | ✓                    | 𐄂                    | ✓                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | 𐄂                  |
+| Confidence                              | 𐄂                    | ✓                    | ✓                    | 𐄂                    | ✓                    | ✓                    | ✓                    | ✓                    | 𐄂                    | 𐄂                       | 𐄂                           | ✓                  | 𐄂                  |
+| Source code extract                     | 𐄂                    | ✓                    | ✓                    | ✓                    | 𐄂                    | ✓                    | ✓                    | 𐄂                    | 𐄂                    | 𐄂                       | 𐄂                           | 𐄂                  | 𐄂                  |
+| Internal ID                             | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | ✓                    | 𐄂                    | 𐄂                    | ✓                       | ✓                           | ✓                  | ✓                  |
 
 - ✓ => we have that data
 - ⚠ => we have that data but it's partially reliable, or we need to extract it from unstructured content
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index f427f33c8c2..95027e99c00 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -73,6 +73,7 @@ The following table shows which languages, package managers and frameworks are s
 | Groovy ([Ant](https://ant.apache.org/), [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) and [SBT](https://www.scala-sbt.org/)) | [SpotBugs](https://spotbugs.github.io/) with the [find-sec-bugs](https://find-sec-bugs.github.io/) plugin | 11.3 (Gradle) & 11.9 (Ant, Maven, SBT) |
 | Java ([Ant](https://ant.apache.org/), [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) and [SBT](https://www.scala-sbt.org/)) | [SpotBugs](https://spotbugs.github.io/) with the [find-sec-bugs](https://find-sec-bugs.github.io/) plugin | 10.6 (Maven), 10.8 (Gradle) & 11.9 (Ant, SBT) |
 | JavaScript                                                                  | [ESLint security plugin](https://github.com/nodesecurity/eslint-plugin-security)       | 11.8                         |
+| Kubernetes manifests                                                        | [Kubesec](https://github.com/controlplaneio/kubesec)                                   | 12.6                         |
 | Node.js                                                                     | [NodeJsScan](https://github.com/ajinabraham/NodeJsScan)                                | 11.1                         |
 | PHP                                                                         | [phpcs-security-audit](https://github.com/FloeDesignTechnologies/phpcs-security-audit) | 10.8                         |
 | Python ([pip](https://pip.pypa.io/en/stable/))                              | [bandit](https://github.com/PyCQA/bandit)                                              | 10.3                         |
@@ -185,6 +186,22 @@ variables:
 
 This will create individual `<analyzer-name>-sast` jobs for each analyzer that runs in your CI/CD pipeline.
 
+#### Enabling kubesec analyzer
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12752) in GitLab Ultimate 12.6.
+
+When [Docker in Docker is disabled](#disabling-docker-in-docker-for-sast),
+you will need to set `SCAN_KUBERNETES_MANIFESTS` to `"true"` to enable the
+kubesec analyzer. In `.gitlab-ci.yml`, define:
+
+```yaml
+include:
+  template: SAST.gitlab-ci.yml
+
+variables:
+  SCAN_KUBERNETES_MANIFESTS: "true"
+```
+
 ### Available variables
 
 SAST can be [configured](#customizing-the-sast-settings) using environment variables.
@@ -206,14 +223,14 @@ The following are Docker image-related variables.
 
 Some analyzers make it possible to filter out vulnerabilities under a given threshold.
 
-| Environment variable | Default value | Description | Example usage |
-|----------------------|---------------|-------------|---|
-| `SAST_BANDIT_EXCLUDED_PATHS`  | -   | comma-separated list of paths to exclude from scan. Uses Python's [`fnmatch` syntax](https://docs.python.org/2/library/fnmatch.html) | |
-| `SAST_BRAKEMAN_LEVEL`   |         1 | Ignore Brakeman vulnerabilities under given confidence level. Integer, 1=Low 3=High. | |
-| `SAST_FLAWFINDER_LEVEL` |         1 | Ignore Flawfinder vulnerabilities under given risk level. Integer, 0=No risk, 5=High risk. | |
-| `SAST_GITLEAKS_ENTROPY_LEVEL` | 8.0 | Minimum entropy for secret detection. Float, 0.0 = low, 8.0 = high. | |
-| `SAST_GOSEC_LEVEL`      |         0 | Ignore gosec vulnerabilities under given confidence level. Integer, 0=Undefined, 1=Low, 2=Medium, 3=High. | |
-| `SAST_EXCLUDED_PATHS`   |   -        | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, file or folder paths. Parent directories will also match patterns. | `SAST_EXCLUDED_PATHS=doc,spec` |
+| Environment variable | Default value | Description |
+|----------------------|---------------|-------------|
+| `SAST_BANDIT_EXCLUDED_PATHS`  | -   | comma-separated list of paths to exclude from scan. Uses Python's [`fnmatch` syntax](https://docs.python.org/2/library/fnmatch.html) |
+| `SAST_BRAKEMAN_LEVEL`   |         1 | Ignore Brakeman vulnerabilities under given confidence level. Integer, 1=Low 3=High. |
+| `SAST_FLAWFINDER_LEVEL` |         1 | Ignore Flawfinder vulnerabilities under given risk level. Integer, 0=No risk, 5=High risk. |
+| `SAST_GITLEAKS_ENTROPY_LEVEL` | 8.0 | Minimum entropy for secret detection. Float, 0.0 = low, 8.0 = high. |
+| `SAST_GOSEC_LEVEL`      |         0 | Ignore gosec vulnerabilities under given confidence level. Integer, 0=Undefined, 1=Low, 2=Medium, 3=High. |
+| `SAST_EXCLUDED_PATHS`   |   -        | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, file or folder paths (e.g., `doc,spec` ). Parent directories will also match patterns. |
 
 #### Timeouts
 
@@ -232,19 +249,20 @@ Timeout variables are not applicable for setups with [disabled Docker In Docker]
 
 Some analyzers can be customized with environment variables.
 
-| Environment variable    | Analyzer | Description |
-|-------------------------|----------|----------|
-| `ANT_HOME`              | spotbugs | The `ANT_HOME` environment variable. |
-| `ANT_PATH`              | spotbugs | Path to the `ant` executable. |
-| `GRADLE_PATH`           | spotbugs | Path to the `gradle` executable. |
-| `JAVA_OPTS`             | spotbugs | Additional arguments for the `java` executable. |
-| `JAVA_PATH`             | spotbugs | Path to the `java` executable. |
-| `SAST_JAVA_VERSION`     | spotbugs | Which Java version to use. Supported versions are `8` and `11`. Defaults to `8`. |
-| `MAVEN_CLI_OPTS`        | spotbugs | Additional arguments for the `mvn` or `mvnw` executable. |
-| `MAVEN_PATH`            | spotbugs | Path to the `mvn` executable. |
-| `MAVEN_REPO_PATH`       | spotbugs | Path to the Maven local repository (shortcut for the `maven.repo.local` property). |
-| `SBT_PATH`              | spotbugs | Path to the `sbt` executable. |
-| `FAIL_NEVER`            | spotbugs | Set to `1` to ignore compilation failure. |
+| Environment variable        | Analyzer | Description |
+|-----------------------------|----------|-------------|
+| `SCAN_KUBERNETES_MANIFESTS` | kubesec  | Set to `"true"` to scan Kubernetes manifests when [Docker in Docker](#disabling-docker-in-docker-for-sast) is disabled. |
+| `ANT_HOME`                  | spotbugs | The `ANT_HOME` environment variable. |
+| `ANT_PATH`                  | spotbugs | Path to the `ant` executable. |
+| `GRADLE_PATH`               | spotbugs | Path to the `gradle` executable. |
+| `JAVA_OPTS`                 | spotbugs | Additional arguments for the `java` executable. |
+| `JAVA_PATH`                 | spotbugs | Path to the `java` executable. |
+| `SAST_JAVA_VERSION`         | spotbugs | Which Java version to use. Supported versions are `8` and `11`. Defaults to `8`. |
+| `MAVEN_CLI_OPTS`            | spotbugs | Additional arguments for the `mvn` or `mvnw` executable. |
+| `MAVEN_PATH`                | spotbugs | Path to the `mvn` executable. |
+| `MAVEN_REPO_PATH`           | spotbugs | Path to the Maven local repository (shortcut for the `maven.repo.local` property). |
+| `SBT_PATH`                  | spotbugs | Path to the `sbt` executable. |
+| `FAIL_NEVER`                | spotbugs | Set to `1` to ignore compilation failure. |
 
 #### Custom environment variables
 
@@ -340,7 +358,7 @@ it highlighted:
 }
 ```
 
-Here is the description of the report file structure nodes and their meaning. All fields are mandatory to be present in
+Here is the description of the report file structure nodes and their meaning. All fields are mandatory in
 the report JSON unless stated otherwise. Presence of optional fields depends on the underlying analyzers being used.
 
 | Report JSON node                        | Function |
diff --git a/doc/user/application_security/security_dashboard/img/group_security_dashboard_v12_4.png b/doc/user/application_security/security_dashboard/img/group_security_dashboard_v12_4.png
deleted file mode 100644
index 682dcbec63f..00000000000
--- a/doc/user/application_security/security_dashboard/img/group_security_dashboard_v12_4.png
+++ /dev/null
diff --git a/doc/user/application_security/security_dashboard/img/group_security_dashboard_v12_6.png b/doc/user/application_security/security_dashboard/img/group_security_dashboard_v12_6.png
new file mode 100644
index 00000000000..c93a3ce8c35
--- /dev/null
+++ b/doc/user/application_security/security_dashboard/img/group_security_dashboard_v12_6.png
diff --git a/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v12_3.png b/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v12_3.png
deleted file mode 100644
index 09979ba99b3..00000000000
--- a/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v12_3.png
+++ /dev/null
diff --git a/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v12_6.png b/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v12_6.png
new file mode 100644
index 00000000000..670c90d10a3
--- /dev/null
+++ b/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v12_6.png
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index 7eb0d649648..bb2bf0b7806 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -42,7 +42,7 @@ At the pipeline level, the Security Dashboard displays the vulnerabilities prese
 
 Visit the page for any pipeline which has run any of the [supported reports](#supported-reports). Click the **Security** tab to view the Security Dashboard.
 
-![Pipeline Security Dashboard](img/pipeline_security_dashboard_v12_3.png)
+![Pipeline Security Dashboard](img/pipeline_security_dashboard_v12_6.png)
 
 ## Project Security Dashboard
 
@@ -71,12 +71,12 @@ Once you're on the dashboard, at the top you should see a series of filters for:
 - Report type
 - Project
 
-To the right of the filters, you should see a **Hide dismissed** toggle button ([available for GitLab.com Gold, planned for GitLab Ultimate 12.6](https://gitlab.com/gitlab-org/gitlab/issues/9102)).
+To the right of the filters, you should see a **Hide dismissed** toggle button.
 
 NOTE: **Note:**
 The dashboard only shows projects with [security reports](#supported-reports) enabled in a group.
 
-![dashboard with action buttons and metrics](img/group_security_dashboard_v12_4.png)
+![dashboard with action buttons and metrics](img/group_security_dashboard_v12_6.png)
 
 Selecting one or more filters will filter the results in this page. Disabling the **Hide dismissed**
 toggle button will let you also see vulnerabilities that have been dismissed.
@@ -97,6 +97,17 @@ vulnerabilities your projects had at various points in time. You can filter amon
 90 days, with the default being 90. Hover over the chart to get more details about
 the open vulnerabilities at a specific time.
 
+Below the timeline chart is a list of projects, grouped and sorted by the severity of the vulnerability found:
+
+- F: 1 or more "critical"
+- D: 1 or more "high" or "unknown"
+- C: 1 or more "medium"
+- B: 1 or more "low"
+- A: 0 vulnerabilities
+
+Projects with no vulnerability tests configured will not appear in the list. Additionally, dismissed
+vulnerabilities are not included either.
+
 Read more on how to [interact with the vulnerabilities](../index.md#interacting-with-the-vulnerabilities).
 
 ## Keeping the dashboards up to date
diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md
index 7ee1650f698..95dbe7d3b51 100644
--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@@ -267,13 +267,19 @@ This feature:
   kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller' | awk '{print $1}') -- tail -f /var/log/modsec/audit.log
   ```
 
-There is a small performance overhead by enabling `modsecurity`. However, if this is
-considered significant for your application, you can toggle the feature flag back to
-false by running the following command within the Rails console:
-
-```ruby
-Feature.disable(:ingress_modsecurity)
-```
+There is a small performance overhead by enabling `modsecurity`. If this is
+considered significant for your application, you can either:
+
+- Disable ModSecurity's rule engine for your deployed application by setting
+  [the deployment variable](../../topics/autodevops/index.md)
+  `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` to `Off`. This will prevent ModSecurity from
+  processing any requests for the given application or environment.
+- Toggle the feature flag to false by running the following command within your
+  instance's Rails console:
+
+  ```ruby
+  Feature.disable(:ingress_modsecurity)
+  ```
 
 Once disabled, you must [uninstall](#uninstalling-applications) and reinstall your Ingress
 application for the changes to take effect.
@@ -429,6 +435,131 @@ administrator to run following command within a Rails console:
 Feature.enable(:enable_cluster_application_crossplane)
 ```
 
+## Install using GitLab CI (alpha)
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/20822) in GitLab 12.6.
+
+CAUTION: **Warning:**
+This is an _alpha_ feature, and it is subject to change at any time without
+prior notice.
+
+This alternative method allows users to install GitLab-managed
+applications using GitLab CI. It also allows customization of the
+install using Helm `values.yaml` files.
+
+Supported applications:
+
+- [Ingress](#install-ingress-using-gitlab-ci)
+- [Sentry](#install-sentry-using-gitlab-ci)
+
+### Usage
+
+To install applications using GitLab CI:
+
+1. Connect the cluster to a [cluster management project](management_project.md).
+1. In that project, add a `.gitlab-ci.yml` file with the following content:
+
+    ```yaml
+    include:
+      - template: Managed-Cluster-Applications.gitlab-ci.yml
+    ```
+
+1. Add a `.gitlab/managed-apps/config.yaml` file to define which
+  applications you would like to install. Define the `installed` key as
+  `true` to install the application and `false` to uninstall the
+  application. For example, to install Ingress:
+
+    ```yaml
+    ingress:
+      installed: true
+    ```
+
+1. Optionally, define `.gitlab/managed-apps/<application>/values.yaml` file to
+   customize values for the installed application.
+
+A GitLab CI pipeline will then run on the `master` branch to install the
+applications you have configured.
+
+### Install Ingress using GitLab CI
+
+To install Ingress, define the `.gitlab/managed-apps/config.yaml` file
+with:
+
+```yaml
+ingress:
+  installed: true
+```
+
+Ingress will then be installed into the `gitlab-managed-apps` namespace
+of your cluster.
+
+You can customize the installation of Ingress by defining
+`.gitlab/managed-apps/ingress/values.yaml` file in your cluster
+management project. Refer to the
+[chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
+for the available configuration options.
+
+### Install Sentry using GitLab CI
+
+NOTE: **Note:**
+The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285) at least 3GB of available RAM for database migrations.
+
+To install Sentry, define the `.gitlab/managed-apps/config.yaml` file
+with:
+
+```yaml
+sentry:
+  installed: true
+```
+
+Sentry will then be installed into the `gitlab-managed-apps` namespace
+of your cluster.
+
+You can customize the installation of Sentry by defining
+`.gitlab/managed-apps/sentry/values.yaml` file in your cluster
+management project. Refer to the
+[chart](https://github.com/helm/charts/tree/master/stable/sentry)
+for the available configuration options.
+
+We recommend you pay close attention to the following configuration options:
+
+- `email`. Needed to invite users to your Sentry instance and to send error emails.
+- `user`. Where you can set the login credentials for the default admin user.
+- `postgresql`. For a PostgreSQL password that can be used when running future updates.
+
+NOTE: **Note:**
+When upgrading it is important to provide the existing PostgreSQL password (given using the `postgresql.postgresqlPassword` key) or you will receive authentication errors. See the [PostgreSQL chart documentation](https://github.com/helm/charts/tree/master/stable/postgresql#upgrade) for more information.
+
+Here is an example configuration for Sentry:
+
+```yaml
+# Admin user to create
+user:
+  # Indicated to create the admin user or not,
+  # Default is true as the initial installation.
+  create: true
+  email: "<your email>"
+  password: "<your password>"
+
+email:
+  from_address: "<your from email>"
+  host: smtp
+  port: 25
+  use_tls: false
+  user: "<your email username>"
+  password: "<your email password>"
+  enable_replies: false
+
+ingress:
+  enabled: true
+  hostname: "<sentry.example.com>"
+
+# Needs to be here between runs.
+# See https://github.com/helm/charts/tree/master/stable/postgresql#upgrade for more info
+postgresql:
+  postgresqlPassword: example-postgresql-password
+```
+
 ## Upgrading applications
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/24789) in GitLab 11.8.
@@ -470,6 +601,7 @@ The applications below can be uninstalled.
 | Knative  | 12.1+         | The associated IP will be deleted and cannot be restored. |
 | Prometheus  | 11.11+         | All data will be deleted and cannot be restored. |
 | Crossplane  | 12.5+         | All data will be deleted and cannot be restored. |
+| Sentry  | 12.6+         | The PostgreSQL persistent volume will remain and should be manually removed for complete uninstall.  |
 
 To uninstall an application:
 
diff --git a/doc/user/clusters/crossplane.md b/doc/user/clusters/crossplane.md
index 37210b22f6f..ee0bd4c33db 100644
--- a/doc/user/clusters/crossplane.md
+++ b/doc/user/clusters/crossplane.md
@@ -220,9 +220,9 @@ The Resource Classes allow you to define classes of service for a managed servic
 
 The Auto DevOps pipeline can be run with the following options:
 
-The Environment variables, `AUTO_DEVOPS_POSTGRES_MANAGED` and `AUTO_DEVOPS_POSTGRES_MANAGED_CLASS_SELECTOR` need to be set to provision PostgresQL using Crossplane
+The Environment variables, `AUTO_DEVOPS_POSTGRES_MANAGED` and `AUTO_DEVOPS_POSTGRES_MANAGED_CLASS_SELECTOR` need to be set to provision PostgreSQL using Crossplane
 
-Alertnatively, the following options can be overridden from the values for the helm chart.
+Alertnatively, the following options can be overridden from the values for the Helm chart.
 
 - `postgres.managed` set to true which will select a default resource class.
      The resource class needs to be marked with the annotation
@@ -237,7 +237,7 @@ Alertnatively, the following options can be overridden from the values for the h
 
 The Auto DevOps pipeline should provision a PostgresqlInstance when it runs succesfully.
 
-Verify creation of the PostgresQL Instance.
+Verify creation of the PostgreSQL Instance.
 
 ```sh
 kubectl get postgresqlinstance
@@ -286,7 +286,7 @@ serverCACertificateInstance:          41 bytes
 serverCACertificateSha1Fingerprint:   40 bytes
 ```
 
-## Connect to the PostgresQL instance
+## Connect to the PostgreSQL instance
 
 Follow this [GCP guide](https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine) if you
 would like to connect to the newly provisioned Postgres database instance on CloudSQL.
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index 83b6f6fe300..57a1f46ac6e 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -55,7 +55,7 @@ To select a cluster management project to use:
 ### Configuring your pipeline
 
 After designating a project as the management project for the cluster,
-write a [`.gitlab-ci,yml`](../../ci/yaml/README.md) in that project. For example:
+write a [`.gitlab-ci.yml`](../../ci/yaml/README.md) in that project. For example:
 
 ```yaml
 configure cluster:
diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md
index dcb75a19b2a..d4e485d7c32 100644
--- a/doc/user/discussions/index.md
+++ b/doc/user/discussions/index.md
@@ -386,7 +386,7 @@ from any device you're logged into.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/18008) in GitLab 11.6.
 
 As a reviewer, you're able to suggest code changes with a simple
-markdown syntax in Merge Request Diff threads. Then, the
+Markdown syntax in Merge Request Diff threads. Then, the
 Merge Request author (or other users with appropriate
 [permission](../permissions.md)) is able to apply these
 suggestions with a click, which will generate a commit in
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 5912fc8e9f9..f174b75abb6 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -14,6 +14,17 @@ Below are the fingerprints for GitLab.com's SSH host keys.
 |  ED25519  | `2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16` | `eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8` |
 |  RSA      | `b6:03:0e:39:97:9e:d0:e7:24:ce:a3:77:3e:01:42:09` | `ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ` |
 
+## SSH `known_hosts` entries
+
+Add the following to `.ssh/known_hosts` to skip manual fingerprint
+confirmation in SSH:
+
+```
+gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
+gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
+gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=
+```
+
 ## Mail configuration
 
 GitLab.com sends emails from the `mg.gitlab.com` domain via [Mailgun] and has
@@ -63,6 +74,7 @@ Below are the current settings regarding [GitLab CI/CD](../../ci/README.md).
 | -----------             | ----------------- | ------------- |
 | Artifacts maximum size (uncompressed) | 1G                | 100M          |
 | Artifacts [expiry time](../../ci/yaml/README.md#artifactsexpire_in)   | kept forever           | deleted after 30 days unless otherwise specified    |
+| Scheduled Pipeline Cron | `*/5 * * * *` | `*/19 * * * *` |
 
 ## Repository size limit
 
@@ -79,7 +91,7 @@ GitLab.com, CI/CD, and related services are deployed into Google Cloud Platform
 IP based firewall can be configured by looking up all
 [IP address ranges or CIDR blocks for GCP](https://cloud.google.com/compute/docs/faq#where_can_i_find_product_name_short_ip_ranges).
 
-[Static endpoints](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5071) are being considered.
+[Static endpoints](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/97) are being considered.
 
 ## Shared Runners
 
@@ -95,6 +107,8 @@ installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
 region of the VMs is US East1.
 Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
 
+The `gitlab-shared-runners-manager-X.gitlab.com` fleet of Runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They will not run untagged jobs and unlike the general fleet of shared Runners, the instances are re-used up to 40 times.
+
 Jobs handled by the shared Runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
 **will be timed out after 3 hours**, regardless of the timeout configured in a
 project. Check the issues [4010] and [4070] for the reference.
@@ -341,19 +355,44 @@ GitLab.com:
   set to the default.
 - Does not have the user and IP rate limits settings enabled.
 
+### Visibility settings
+
+On GitLab.com, projects, groups, and snippets created
+As of GitLab 12.2 (July 2019), projects, groups, and snippets have the
+[**Internal** visibility](../../public_access/public_access.md#internal-projects) setting [disabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/issues/12388).
+
+## GitLab.com Logging
+
+We use [Fluentd](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#fluentd) to parse our logs. Fluentd sends our logs to
+[Stackdriver Logging](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#stackdriver) and [Cloud Pub/Sub](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#cloud-pubsub).
+Stackdriver is used for storing logs long-term in Google Cold Storage (GCS). Cloud Pub/Sub
+is used to forward logs to an [Elastic cluster](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#elastic) using [pubsubbeat](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#pubsubbeat-vms).
+
+You can view more information in our runbooks such as:
+
+- A [detailed list of what we're logging](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#what-are-we-logging)
+- Our [current log retention policies](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#retention)
+- A [diagram of our logging infrastructure](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#logging-infrastructure-overview)
+
 ## GitLab.com at scale
 
 In addition to the GitLab Enterprise Edition Omnibus install, GitLab.com uses
 the following applications and settings to achieve scale. All settings are
 publicly available at [chef cookbooks](https://gitlab.com/gitlab-cookbooks).
 
-### ELK
+### Elastic Cluster
 
-We use Elasticsearch, logstash, and Kibana for part of our monitoring solution:
+We use Elasticsearch and Kibana for part of our monitoring solution:
 
 - [`gitlab-cookbooks` / `gitlab-elk` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
 - [`gitlab-cookbooks` / `gitlab_elasticsearch` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
 
+### Fluentd
+
+We use Fluentd to unify our GitLab logs:
+
+- [`gitlab-cookbooks` / `gitlab_fluentd` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd)
+
 ### Prometheus
 
 Prometheus complete our monitoring stack:
@@ -393,11 +432,3 @@ High Performance TCP/HTTP Load Balancer:
 [unicorn-worker-killer]: https://rubygems.org/gems/unicorn-worker-killer "unicorn-worker-killer"
 [4010]: https://gitlab.com/gitlab-com/infrastructure/issues/4010 "Find a good value for maximum timeout for Shared Runners"
 [4070]: https://gitlab.com/gitlab-com/infrastructure/issues/4070 "Configure per-runner timeout for shared-runners-manager-X on GitLab.com"
-
-## Group and project settings
-
-On GitLab.com, projects, groups, and snippets created
-after July 2019 have the `Internal` visibility setting disabled.
-
-You can read more about the change in the
-[relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/12388).
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index 1fe456902a2..2b36c3bdf5b 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -75,6 +75,21 @@ NOTE: **Note:**
 If you [install applications](#installing-applications) on your cluster, GitLab will create
 the resources required to run these even if you have chosen to manage your own cluster.
 
+### Clearing the cluster cache
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31759) in GitLab 12.6.
+
+If you choose to allow GitLab to manage your cluster for you, GitLab stores a cached
+version of the namespaces and service accounts it creates for your projects. If you
+modify these resources in your cluster manually, this cache can fall out of sync with
+your cluster, which can cause deployment jobs to fail.
+
+To clear the cache:
+
+1. Navigate to your group’s **Kubernetes** page, and select your cluster.
+1. Expand the **Advanced settings** section.
+1. Click **Clear cluster cache**.
+
 ## Base domain
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/24580) in GitLab 11.8.
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 5f45a462f94..ad16aaa34ff 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -431,6 +431,23 @@ To enable this feature:
 1. Expand the **Permissions, LFS, 2FA** section, and select **Disable email notifications**.
 1. Click **Save changes**.
 
+#### Disabling group mentions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/21301) in GitLab 12.6.
+
+You can prevent users from being added to a conversation and getting notified when
+anyone mentions a group in which those users are members.
+
+Groups with disabled mentions are visualized accordingly in the autocompletion dropdown.
+
+This is particularly helpful for groups with a large number of users.
+
+To enable this feature:
+
+1. Navigate to the group's **Settings > General** page.
+1. Expand the **Permissions, LFS, 2FA** section, and select **Disable group mentions**.
+1. Click **Save changes**.
+
 ### Advanced settings
 
 - **Projects**: View all projects within that group, add members to each project,
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 6fd56414796..5fe2d0da5c8 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -2,19 +2,23 @@
 type: reference, howto
 ---
 
-# SAML SSO for GitLab.com Groups **(SILVER ONLY)**
+# SAML SSO for GitLab.com groups **(SILVER ONLY)**
 
 > Introduced in [GitLab.com Silver](https://about.gitlab.com/pricing/) 11.0.
 
-NOTE: **Note:**
-This topic is for SAML on GitLab.com Silver tier and above. For SAML on self-managed GitLab instances, see [SAML OmniAuth Provider](../../../integration/saml.md).
-
 SAML on GitLab.com allows users to be automatically added to a group, and then allows those users to sign into GitLab.com. Users should already have an account on the GitLab instance, or can create one when logging in for the first time.
 
 User synchronization for GitLab.com is partially supported using [SCIM](scim_setup.md).
 
-NOTE: **Note:**
-SAML SSO for GitLab.com groups does not sync users between providers without using SCIM. If a group is not using SCIM, group Owners will still need to manage user accounts (for example, removing users when necessary).
+## Important notes
+
+Note the following:
+
+- This topic is for SAML on GitLab.com Silver tier and above. For SAML on self-managed GitLab
+  instances, see [SAML OmniAuth Provider](../../../integration/saml.md).
+- SAML SSO for GitLab.com groups requires SCIM to sync users between providers. If a
+  group is not using SCIM, group Owners will still need to manage user accounts (for example,
+  removing users when necessary).
 
 ## Configuring your Identity Provider
 
@@ -68,16 +72,17 @@ When this option is enabled:
 
 - All existing and new users in the group will be required to log in via the SSO URL associated with the group.
 - On successfully authenticating, GitLab will prompt the user to create a new, dedicated account using the email address received from the configured identity provider.
-- After the group managed account has been created, group activity will require the use of this user account.
+- After the group-managed account has been created, group activity will require the use of this user account.
 
-Since use of the group managed account requires the use of SSO, users of group managed accounts will lose access to these accounts when they are no longer able to authenticate with the connected identity provider. In the case of an offboarded employee who has been removed from your identity provider:
+Since use of the group-managed account requires the use of SSO, users of group-managed accounts will lose access to these accounts when they are no longer able to authenticate with the connected identity provider. In the case of an offboarded employee who has been removed from your identity provider:
 
 - The user will be unable to access the group (their credentials will no longer work on the identity provider when prompted to SSO).
 - Contributions in the group (e.g. issues, merge requests) will remain intact.
 
 #### Assertions
 
-When using Group Manged Accounts, the following user details need to be passed to GitLab as SAML Assertions in order for us to be able to create a user:
+When using group-managed accounts, the following user details need to be passed to GitLab as SAML
+assertions to be able to create a user.
 
 | Field           | Supported keys |
 |-----------------|----------------|
@@ -91,7 +96,7 @@ When using Group Manged Accounts, the following user details need to be passed t
 GitLab provides metadata XML that can be used to configure your Identity Provider.
 
 1. Navigate to the group and click **Settings > SAML SSO**.
-1. Copy the provided **GitLab metadata URL**
+1. Copy the provided **GitLab metadata URL**.
 1. Follow your Identity Provider's documentation and paste the metadata URL when it is requested.
 
 ## Configuring GitLab
@@ -123,6 +128,25 @@ NOTE: **Note:** GitLab is unable to provide support for IdPs that are not listed
 
 When [configuring your identify provider](#configuring-your-identity-provider), please consider the notes below for specific providers to help avoid common issues and as a guide for terminology used.
 
+### Azure setup notes
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For a demo of the Azure SAML setup including SCIM, see [SCIM Provisioning on Azure Using SAML SSO for Groups Demo](https://youtu.be/24-ZxmTeEBU).
+
+| GitLab Setting | Azure Field |
+|--------------|----------------|
+| Identifier   | Identifier (Entity ID) |
+| Assertion consumer service URL | Reply URL (Assertion Consumer Service URL) |
+| Identity provider single sign on URL | Login URL |
+| Certificate fingerprint | Thumbprint |
+
+We recommend:
+
+- **Unique User Identifier (Name identifier)** set to `user.objectID`.
+- **nameid-format** set to persistent.
+
+Set other user attributes and claims according to the [assertions table](#assertions).
+
 ### Okta setup notes
 
 | GitLab Setting | Okta Field |
@@ -193,6 +217,8 @@ For example, to unlink the `MyOrg` account, the following **Disconnect** button
 
 ## Troubleshooting
 
+This section contains possible solutions for problems you might encounter.
+
 ### SAML debugging tools
 
 SAML responses are base64 encoded, so we recommend the following browser plugins to decode them on the fly:
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 392b27bb42f..a117364a355 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -2,7 +2,7 @@
 type: howto, reference
 ---
 
-# SCIM provisioning using SAML SSO for Groups **(SILVER ONLY)**
+# SCIM provisioning using SAML SSO for GitLab.com groups **(SILVER ONLY)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/9388) in [GitLab.com Silver](https://about.gitlab.com/pricing/) 11.10.
 
@@ -24,7 +24,7 @@ The following identity providers are supported:
 
 ## Requirements
 
-- [Group SSO](index.md) needs to be configured.
+- [Group SSO](index.md) must be configured.
 
 ## GitLab configuration
 
@@ -64,15 +64,25 @@ You can then test the connection by clicking on **Test Connection**. If the conn
 
 1. Click on `Synchronize Azure Active Directory Users to AppName`, to configure the attribute mapping.
 1. Click **Delete** next to the `mail` mapping.
-1. Map `userPrincipalName` to `emails[type eq "work"].value` and change it's **Matching precedence** to `2`.
+1. Map `userPrincipalName` to `emails[type eq "work"].value` and change its **Matching precedence** to `2`.
 1. Map `mailNickname` to `userName`.
 1. Determine how GitLab will uniquely identify users.
 
     - Use `objectId` unless users already have SAML linked for your group.
     - If you already have users with SAML linked then use the `Name ID` value from the [SAML configuration](#azure). Using a different value will likely cause duplicate users and prevent users from accessing the GitLab group.
 
-1. Create a new mapping by clicking **Add New Mapping** then set **Source attribute** to the unique identifier determined above, **Target attribute** to `id`, **Match objects using this attribute** to `Yes`, and **Matching precedence** to `1`.
-1. Create a new mapping by clicking **Add New Mapping** then set **Source attribute** to the unique identifier determined above, and **Target attribute** to `externalId`.
+1. Create a new mapping:
+   1. Click **Add New Mapping**.
+   1. Set:
+      - **Source attribute** to the unique identifier determined above.
+      - **Target attribute** to `id`.
+      - **Match objects using this attribute** to `Yes`.
+      - **Matching precedence** to `1`.
+1. Create another new mapping:
+   1. Click **Add New Mapping**.
+   1. Set:
+      - **Source attribute** to the unique identifier determined above.
+      - **Target attribute** to `externalId`.
 1. Click the `userPrincipalName` mapping and change **Match objects using this attribute** to `No`.
 
    Save your changes and you should have the following configuration:
@@ -109,6 +119,8 @@ Once synchronized, changing the field mapped to `id` and `externalId` will likel
 
 ## Troubleshooting
 
+This section contains possible solutions for problems you might encounter.
+
 ### Testing Azure connection: invalid credentials
 
 When testing the connection, you may encounter an error: **You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account**. If `Tenant URL` and `secret token` are correct, check whether your group path contains characters that may be considered invalid JSON primitives (such as `.`). Removing such characters from the group path typically resolves the error.
diff --git a/doc/user/group/subgroups/img/group_members_filter_v12_6.png b/doc/user/group/subgroups/img/group_members_filter_v12_6.png
new file mode 100644
index 00000000000..0207515ded0
--- /dev/null
+++ b/doc/user/group/subgroups/img/group_members_filter_v12_6.png
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 52b7035389a..997cb1ba6c5 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -4,7 +4,7 @@ type: reference, howto, concepts
 
 # Subgroups
 
->[Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
 
 Subgroups, also known as nested groups or hierarchical groups, allow you to have up to 20
 levels of groups.
@@ -142,6 +142,16 @@ From the image above, we can deduce the following things:
 - Administrator is the Owner and member of **all** subgroups and for that reason,
   as with User3, there is no indication of an ancestor group.
 
+[From](https://gitlab.com/gitlab-org/gitlab/issues/21727) GitLab 12.6, you can filter
+this list using dropdown on the right side:
+
+![Group members filter](img/group_members_filter_v12_6.png)
+
+- **Show only direct members** displays only Administrator and User3, since these are
+  the only users that belong to group `four`, which is the one we're inspecting.
+- **Show only inherited members** displays User0, User1 and User2, no matter which group
+  above the hierarchy is the source of inherited permissions.
+
 ### Overriding the ancestor group membership
 
 NOTE: **Note:**
@@ -186,7 +196,7 @@ Here's a list of what you can't do with subgroups:
 
 [ce-2772]: https://gitlab.com/gitlab-org/gitlab-foss/issues/2772
 [permissions]: ../../permissions.md#group-members-permissions
-[reserved]:  ../../reserved_names.md
+[reserved]: ../../reserved_names.md
 [issue]: https://gitlab.com/gitlab-org/gitlab-foss/issues/30472#note_27747600
 
 <!-- ## Troubleshooting
diff --git a/doc/user/incident_management/index.md b/doc/user/incident_management/index.md
index 5ac27d227a1..febe1a2423a 100644
--- a/doc/user/incident_management/index.md
+++ b/doc/user/incident_management/index.md
@@ -91,7 +91,7 @@ Please refer to a list of [available slash commands](../../integration/slash_com
 
 ## Zoom in issues
 
-In order to communicate synchronously for incidents management, GitLab allows to
+In order to communicate synchronously for incidents management, GitLab allows you to
 associate a Zoom meeting with an issue. Once you start a Zoom call for a fire-fight,
 you need a way to associate the conference call with an issue, so that your team
 members can join swiftly without requesting a link.
diff --git a/doc/user/infrastructure/index.md b/doc/user/infrastructure/index.md
new file mode 100644
index 00000000000..a50cdf1cf0e
--- /dev/null
+++ b/doc/user/infrastructure/index.md
@@ -0,0 +1,6 @@
+# Infrastructure as Code
+
+GitLab can be used to manage infrastructure as code. The following are some examples:
+
+- [A generic tutorial for Terraform with GitLab](https://medium.com/@timhberry/terraform-pipelines-in-gitlab-415b9d842596).
+- [Terraform at GitLab](https://about.gitlab.com/blog/2019/11/12/gitops-part-2/).
diff --git a/doc/user/instance_statistics/convdev.md b/doc/user/instance_statistics/dev_ops_score.md
index 705f9be3d94..fbe4cc3c6df 100644
--- a/doc/user/instance_statistics/convdev.md
+++ b/doc/user/instance_statistics/dev_ops_score.md
@@ -1,12 +1,12 @@
-# Conversational Development Index
+# DevOps Score
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/30469) in GitLab 9.3.
+> [Renamed from Conversational Development Index](https://gitlab.com/gitlab-org/gitlab/issues/20976) in GitLab 12.6.
 
 NOTE: **Note:**
 Your GitLab instance's [usage ping](../admin_area/settings/usage_statistics.md#usage-ping-core-only) must be activated in order to use this feature.
 
-The [Conversational Development](http://conversationaldevelopment.com/2017/04/16/what-is-conversational-development/) Index (ConvDev Index) gives you an overview of your entire
-instance's adoption of [Concurrent DevOps](https://about.gitlab.com/concurrent-devops/)
+The DevOps Score gives you an overview of your entire instance's adoption of
+[Concurrent DevOps](https://about.gitlab.com/concurrent-devops/)
 from planning to monitoring.
 
 This displays the usage of these GitLab features over
@@ -16,7 +16,7 @@ of top-performing instances based on [usage ping data](../admin_area/settings/us
 collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
 Your overall index score is an average of all your feature score percentages - this percentage value is presented above all the of features on the page.
 
-![ConvDev index](img/convdev_index.png)
+![DevOps Score](img/dev_ops_score.png)
 
 The page also provides helpful links to articles and GitLab docs, to help you
 improve your scores.
diff --git a/doc/user/instance_statistics/img/cohorts.png b/doc/user/instance_statistics/img/cohorts.png
index 12e839e7cd2..4d070fdb654 100644
--- a/doc/user/instance_statistics/img/cohorts.png
+++ b/doc/user/instance_statistics/img/cohorts.png
diff --git a/doc/user/instance_statistics/img/convdev_index.png b/doc/user/instance_statistics/img/dev_ops_score.png
index bee1317438d..bee1317438d 100644
--- a/doc/user/instance_statistics/img/convdev_index.png
+++ b/doc/user/instance_statistics/img/dev_ops_score.png
diff --git a/doc/user/instance_statistics/index.md b/doc/user/instance_statistics/index.md
index fe8e8c96f81..53bf85b6e13 100644
--- a/doc/user/instance_statistics/index.md
+++ b/doc/user/instance_statistics/index.md
@@ -12,5 +12,5 @@ and can be accessed via the top bar.
 
 There are two kinds of statistics:
 
-- [Conversational Development (ConvDev) Index](convdev.md): Provides an overview of your entire instance's feature usage.
+- [Dev Ops Score](dev_ops_score.md): Provides an overview of your entire instance's feature usage.
 - [User Cohorts](user_cohorts.md): Display the monthly cohorts of new users and their activities over time.
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index 3bd0dcafc19..fdf6cb3c7be 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -1,9 +1,9 @@
 # GitLab Markdown
 
-This markdown guide is **valid only for GitLab's internal markdown rendering system for entries and files**.
+This Markdown guide is **valid only for GitLab's internal Markdown rendering system for entries and files**.
 It is **not** valid for the [GitLab documentation website](https://docs.gitlab.com)
 or [GitLab's main website](https://about.gitlab.com), as they both use
-[Kramdown](https://kramdown.gettalong.org) as their markdown engine. The documentation
+[Kramdown](https://kramdown.gettalong.org) as their Markdown engine. The documentation
 website uses an extended Kramdown gem, [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown).
 Consult the [GitLab Kramdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/)
 for a complete Kramdown reference.
@@ -40,7 +40,7 @@ repositories are also processed with CommonMark. As of 11.8, the [Redcarpet Ruby
 has been removed and all issues and comments, including those from pre-11.1, are now processed
 using the [CommonMark Ruby Library](https://github.com/gjtorikian/commonmarker).
 
-The documentation website had its [markdown engine migrated from Redcarpet to Kramdown](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/108)
+The documentation website had its [Markdown engine migrated from Redcarpet to Kramdown](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/108)
 in October 2018.
 
 You may have older issues, merge requests, or Markdown documents in your
@@ -71,7 +71,7 @@ the top list item (`C` in this case):
    - milk
 
 NOTE: **Note:** We will flag any significant differences between Redcarpet and CommonMark
-  markdown in this document.
+  Markdown in this document.
 
 If you have a large volume of Markdown files, it can be tedious to determine
 if they will display correctly or not. You can use the
@@ -81,28 +81,28 @@ differences between how RedCarpet and CommonMark render the files. It can give
 an indication if anything needs to be changed - often nothing will need
 to change.
 
-### GFM extends standard markdown
+### GFM extends standard Markdown
 
 GitLab makes full use of the standard (CommonMark) formatting, but also includes additional
 functionality useful for GitLab users.
 
-It makes use of [new markdown features](#new-GFM-markdown-extensions),
-not found in standard markdown:
+It makes use of [new Markdown features](#new-GFM-markdown-extensions),
+not found in standard Markdown:
 
 - [Color "chips" written in HEX, RGB or HSL](#colors)
-- [Diagrams and flowcharts using Mermaid](#diagrams-and-flowcharts-using-mermaid)
+- [Diagrams and flowcharts](#diagrams-and-flowcharts)
 - [Emoji](#emoji)
 - [Front matter](#front-matter)
 - [Inline diffs](#inline-diff)
 - [Math equations and symbols written in LaTeX](#math)
 - [Special GitLab references](#special-gitlab-references)
 - [Task Lists](#task-lists)
-- [Wiki specific markdown](#wiki-specific-markdown)
+- [Wiki specific Markdown](#wiki-specific-markdown)
 
-It also has [extended markdown features](#standard-markdown-and-extensions-in-gitlab), without
-changing how standard markdown is used:
+It also has [extended Markdown features](#standard-markdown-and-extensions-in-gitlab), without
+changing how standard Markdown is used:
 
-| Standard markdown                     | Extended markdown in GitLab |
+| Standard Markdown                     | Extended Markdown in GitLab |
 | ------------------------------------- | ------------------------- |
 | [blockquotes](#blockquotes)           | [multiline blockquotes](#multiline-blockquote) |
 | [code blocks](#code-spans-and-blocks) | [colored code and syntax highlighting](#colored-code-and-syntax-highlighting) |
@@ -112,7 +112,7 @@ changing how standard markdown is used:
 | [linebreaks](#line-breaks)            | [more linebreak control](#newlines) |
 | [links](#links)                       | [automatically linking URLs](#url-auto-linking) |
 
-## New GFM markdown extensions
+## New GFM Markdown extensions
 
 ### Colors
 
@@ -151,13 +151,16 @@ Color written inside backticks will be followed by a color "chip":
 `HSL(540,70%,50%)`  
 `HSLA(540,70%,50%,0.3)`  
 
-### Diagrams and flowcharts using Mermaid
+### Diagrams and flowcharts
+
+It is possible to generate diagrams and flowcharts from text in GitLab using [Mermaid](https://mermaidjs.github.io/) or [PlantUML](http://plantuml.com).
+
+#### Mermaid
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15107) in
 GitLab 10.3.
 
-It is possible to generate diagrams and flowcharts from text using [Mermaid](https://mermaidjs.github.io/).
-Visit the official page for more details.
+Visit the [official page](https://mermaidjs.github.io/) for more details.
 
 In order to generate a diagram or flowchart, you should write your text inside the `mermaid` block:
 
@@ -179,8 +182,6 @@ graph TD;
   C-->D;
 ```
 
-#### Subgraphs
-
 Subgraphs can also be included:
 
 ~~~
@@ -219,6 +220,10 @@ graph TB
 end
 ```
 
+#### PlantUML
+
+To make PlantUML available in GitLab, a GitLab administrator needs to enable it first. Read more in [PlantUML & GitLab](../administration/integration/plantuml.md).
+
 ### Emoji
 
 > If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#emoji).
@@ -258,7 +263,7 @@ this font installed by default.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/23331) in GitLab 11.6.
 
-Front matter is metadata included at the beginning of a markdown document, preceding
+Front matter is metadata included at the beginning of a Markdown document, preceding
 its content. This data can be used by static site generators such as [Jekyll](https://jekyllrb.com/docs/front-matter/),
 [Hugo](https://gohugo.io/content-management/front-matter/), and many other applications.
 
@@ -529,9 +534,9 @@ This snippet links to `<wiki_root>/miscellaneous.md`:
 
 Metric charts can be embedded within GitLab Flavored Markdown. See [Embedding Metrics within GitLab flavored Markdown](../user/project/integrations/prometheus.md#embedding-metric-charts-within-gitlab-flavored-markdown) for more details.
 
-## Standard markdown and extensions in GitLab
+## Standard Markdown and extensions in GitLab
 
-All standard markdown formatting should work as expected within GitLab. Some standard
+All standard Markdown formatting should work as expected within GitLab. Some standard
 functionality is extended with additional features, without affecting the standard usage.
 If a functionality is extended, the new option will be listed as a sub-section.
 
@@ -560,7 +565,7 @@ Quote break.
 
 > If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#multiline-blockquote).
 
-GFM extends the standard markdown standard by also supporting multiline blockquotes
+GFM extends the standard Markdown standard by also supporting multiline blockquotes
 fenced by `>>>`:
 
 ```
@@ -704,7 +709,7 @@ But let's throw in a <b>tag</b>.
 
 ### Emphasis
 
-There are multiple ways to emphasize text in markdown. You can italicize, bold, strikethrough,
+There are multiple ways to emphasize text in Markdown. You can italicize, bold, strikethrough,
 as well as combine these emphasis styles together.
 
 Examples:
@@ -735,8 +740,8 @@ NOTE: **Note:** Strikethrough is not part of the core Markdown standard, but is
 
 It is not usually useful to italicize just _part_ of a word, especially when you're
 dealing with code and names that often appear with multiple underscores. As a result,
-GFM extends the standard markdown standard by ignoring multiple underlines in words,
-to allow better rendering of markdown documents discussing code:
+GFM extends the standard Markdown standard by ignoring multiple underlines in words,
+to allow better rendering of Markdown documents discussing code:
 
 ```md
 perform_complicated_task
@@ -768,7 +773,7 @@ do*this*and*do*that*and*another thing
 
 ### Footnotes
 
-Footnotes add a link to a note rendered at the end of a markdown file:
+Footnotes add a link to a note rendered at the end of a Markdown file:
 
 ```markdown
 You can add footnotes to your text as follows.[^1]
@@ -801,7 +806,7 @@ Alt-H2
 
 #### Header IDs and links
 
-GFM extends the standard markdown standard so that all Markdown-rendered headers automatically
+GFM extends the standard Markdown standard so that all Markdown-rendered headers automatically
 get IDs, which can be linked to, except in comments.
 
 On hover, a link to those IDs becomes visible to make it easier to copy the link to
@@ -906,7 +911,7 @@ Here's a sample video:
 > If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#audio).
 
 Similar to videos, link tags for files with an audio extension are automatically converted to
-an audio player. The valid audio extensions are `.mp3`, `.ogg`, and `.wav`:
+an audio player. The valid audio extensions are `.mp3`, `.oga`, `.ogg`, `.spx`, and `.wav`:
 
 ```md
 Here's a sample audio clip:
@@ -920,7 +925,7 @@ Here's a sample audio clip:
 
 ### Inline HTML
 
-> To see the markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html).
+> To see the Markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html).
 
 You can also use raw HTML in your Markdown, and it'll usually work pretty well.
 
@@ -948,7 +953,7 @@ class for the list of allowed HTML tags and attributes.  In addition to the defa
 
 ---
 
-It is still possible to use markdown inside HTML tags, but only if the lines containing markdown
+It is still possible to use Markdown inside HTML tags, but only if the lines containing Markdown
 are separated into their own lines:
 
 ```html
@@ -965,7 +970,7 @@ are separated into their own lines:
 </dl>
 ```
 
-<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, markdown will be fine in GitLab -->
+<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, Markdown will be fine in GitLab -->
 
 <dl>
   <dt>Markdown in HTML</dt>
@@ -981,7 +986,7 @@ are separated into their own lines:
 
 #### Details and Summary
 
-> To see the markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#details-and-summary).
+> To see the Markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#details-and-summary).
 
 Content can be collapsed using HTML's [`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details)
 and [`<summary>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary)
@@ -1029,7 +1034,7 @@ PASTE LOGS HERE
 </details>
 ````
 
-<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, markdown will be fine in GitLab -->
+<!-- Note: The example below uses HTML to force correct rendering on docs.gitlab.com, Markdown will be fine in GitLab -->
 
 <details>
 <summary>Click me to collapse/fold.</summary>
@@ -1070,7 +1075,7 @@ in the *same paragraph*.
 
 #### Newlines
 
-GFM adheres to the markdown specification in how [paragraphs and line breaks are handled](https://spec.commonmark.org/current/).
+GFM adheres to the Markdown specification in how [paragraphs and line breaks are handled](https://spec.commonmark.org/current/).
 
 A paragraph is simply one or more consecutive lines of text, separated by one or
 more blank lines (i.e. two newlines at the end of the first paragraph), as [explained above](#line-breaks).
@@ -1117,7 +1122,7 @@ There are two ways to create links, inline-style and reference-style:
 
 Using header ID anchors:
 
-- This links to [a section on a different markdown page, using a "#" and the header ID](index.md#overview)
+- This links to [a section on a different Markdown page, using a "#" and the header ID](index.md#overview)
 - This links to [a different section on the same page, using a "#" and the header ID](#header-ids-and-links)
 
 Using references:
@@ -1140,7 +1145,7 @@ Some text to show that the reference links can follow later.
 
 Using header ID anchors:
 
-- This links to [a section on a different markdown page, using a "#" and the header ID](index.md#overview)
+- This links to [a section on a different Markdown page, using a "#" and the header ID](index.md#overview)
 - This links to [a different section on the same page, using a "#" and the header ID](#header-ids-and-links)
 
 Using references:
@@ -1158,7 +1163,7 @@ Some text to show that the reference links can follow later.
 NOTE: **Note:** Relative links do not allow the referencing of project files in a wiki
 page, or a wiki page in a project file. The reason for this is that a wiki is always
 in a separate Git repository in GitLab. For example, `[I'm a reference-style link](style)`
-will point the link to `wikis/style` only when the link is inside of a wiki markdown file.
+will point the link to `wikis/style` only when the link is inside of a wiki Markdown file.
 
 #### URL auto-linking
 
@@ -1314,7 +1319,7 @@ Tables aren't part of the core Markdown spec, but they are part of GFM.
 1. The first line contains the headers, separated by "pipes" (`|`).
 1. The second line separates the headers from the cells, and must contain three or more dashes.
 1. The third, and any following lines, contain the cell values.
-   - You **can't** have cells separated over many lines in the markdown, they must be kept to single lines,
+   - You **can't** have cells separated over many lines in the Markdown, they must be kept to single lines,
      but they can be very long. You can also include HTML `<br>` tags to force newlines if needed.
    - The cell sizes **don't** have to match each other. They are flexible, but must be separated
      by pipes (`|`).
@@ -1357,6 +1362,6 @@ to the sides of the "dash" lines in the second row. This will affect every cell
 
 - This document leveraged heavily from the [Markdown-Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
 - The original [Markdown Syntax Guide](https://daringfireball.net/projects/markdown/syntax)
-  at Daring Fireball is an excellent resource for a detailed explanation of standard markdown.
+  at Daring Fireball is an excellent resource for a detailed explanation of standard Markdown.
 - The detailed specification for CommonMark can be found in the [CommonMark Spec](https://spec.commonmark.org/current/)
 - The [CommonMark Dingus](http://try.commonmark.org) is a handy tool for testing CommonMark syntax.
diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md
index 953c7472f4d..2366d1ccc0d 100644
--- a/doc/user/packages/conan_repository/index.md
+++ b/doc/user/packages/conan_repository/index.md
@@ -1,6 +1,6 @@
 # GitLab Conan Repository **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/8248) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.5.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/8248) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.6.
 
 With the GitLab Conan Repository, every
 project can have its own space to store Conan packages.
@@ -27,7 +27,7 @@ get familiar with the package naming convention.
 
 ## Authenticating to the GitLab Conan Repository
 
-You will need to generate a [personal access token](../../../user/profile/personal_access_tokens.md) for repository authentication.
+You will need to generate a [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `api` for repository authentication.
 
 Now you can run conan commands using your token.
 
diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md
index f6c9a2c9e34..9c1a9d5a41a 100644
--- a/doc/user/packages/container_registry/index.md
+++ b/doc/user/packages/container_registry/index.md
@@ -144,7 +144,6 @@ project or branch name. Special characters can include:
 
 - Leading underscore
 - Trailing hyphen/dash
-- Double hyphen/dash
 
 To get around this, you can [change the group path](../../group/index.md#changing-a-groups-path),
 [change the project path](../../project/settings/index.md#renaming-a-repository) or change the branch
diff --git a/doc/user/packages/index.md b/doc/user/packages/index.md
index 9873bd80e8b..ecaad960340 100644
--- a/doc/user/packages/index.md
+++ b/doc/user/packages/index.md
@@ -13,8 +13,12 @@ The Packages feature allows GitLab to act as a repository for the following:
 | [Conan Repository](conan_repository/index.md) **(PREMIUM)** | The GitLab Conan Repository enables every project in GitLab to have its own space to store [Conan](https://conan.io/) packages. | 12.4+ |
 | [Maven Repository](maven_repository/index.md) **(PREMIUM)** | The GitLab Maven Repository enables every project in GitLab to have its own space to store [Maven](https://maven.apache.org/) packages. | 11.3+ |
 | [NPM Registry](npm_registry/index.md) **(PREMIUM)**  | The GitLab NPM Registry enables every project in GitLab to have its own space to store [NPM](https://www.npmjs.com/) packages. | 11.7+ |
+| [NuGet Repository](https://gitlab.com/gitlab-org/gitlab/issues/20050) **(PREMIUM)**  | *COMING SOON* The GitLab NuGet Repository will enable every project in GitLab to have its own space to store [NuGet](https://www.nuget.org/) packages. | 12.7 (planned) |
 
 TIP: **Tip:**
 Don't you see your package management system supported yet? Consider contributing
 to GitLab. This [development documentation](../../development/packages.md) will
-guide you through the process.
+guide you through the process. Or check out how other members of the commmunity
+are adding support for [PHP](https://gitlab.com/gitlab-org/gitlab/merge_requests/17417) or [Terraform](https://gitlab.com/gitlab-org/gitlab/merge_requests/18834).
+
+NOTE: **Note** We are especially interested in adding support for [PyPi](https://gitlab.com/gitlab-org/gitlab/issues/10483), [RubyGems](https://gitlab.com/gitlab-org/gitlab/issues/803), [Debian](https://gitlab.com/gitlab-org/gitlab/issues/5835), and [RPM](https://gitlab.com/gitlab-org/gitlab/issues/5932).
diff --git a/doc/user/packages/maven_repository/img/maven_package_view.png b/doc/user/packages/maven_repository/img/maven_package_view.png
deleted file mode 100644
index 2eb4b6f76b4..00000000000
--- a/doc/user/packages/maven_repository/img/maven_package_view.png
+++ /dev/null
diff --git a/doc/user/packages/maven_repository/img/maven_package_view_v12_6.png b/doc/user/packages/maven_repository/img/maven_package_view_v12_6.png
new file mode 100644
index 00000000000..92cefc26660
--- /dev/null
+++ b/doc/user/packages/maven_repository/img/maven_package_view_v12_6.png
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index 8ed10c09891..da5139fcaf9 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -5,7 +5,7 @@
 With the GitLab [Maven](https://maven.apache.org) Repository, every
 project can have its own space to store its Maven artifacts.
 
-![GitLab Maven Repository](img/maven_package_view.png)
+![GitLab Maven Repository](img/maven_package_view_v12_6.png)
 
 ## Enabling the Maven Repository
 
@@ -37,7 +37,7 @@ credentials do not work.
 ### Authenticating with a personal access token
 
 To authenticate with a [personal access token](../../profile/personal_access_tokens.md),
-add a corresponding section to your
+set the scope to `api` and add a corresponding section to your
 [`settings.xml`](https://maven.apache.org/settings.html) file:
 
 ```xml
diff --git a/doc/user/packages/npm_registry/img/npm_package_view.png b/doc/user/packages/npm_registry/img/npm_package_view.png
deleted file mode 100644
index e0634718c02..00000000000
--- a/doc/user/packages/npm_registry/img/npm_package_view.png
+++ /dev/null
diff --git a/doc/user/packages/npm_registry/img/npm_package_view_v12_5.png b/doc/user/packages/npm_registry/img/npm_package_view_v12_5.png
new file mode 100644
index 00000000000..a6f823011eb
--- /dev/null
+++ b/doc/user/packages/npm_registry/img/npm_package_view_v12_5.png
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index d8b59ae63d0..7d5db5a60ef 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -5,7 +5,7 @@
 With the GitLab NPM Registry, every
 project can have its own space to store NPM packages.
 
-![GitLab NPM Registry](img/npm_package_view.png)
+![GitLab NPM Registry](img/npm_package_view_v12_5.png)
 
 NOTE: **Note:**
 Only [scoped](https://docs.npmjs.com/misc/scope) packages are supported.
@@ -42,6 +42,20 @@ it is not possible due to a naming collision. For example:
 | `gitlab-org/gitlab`    | `@gitlab-org/gitlab`    | Yes       |
 | `gitlab-org/gitlab`    | `@foo/bar`              | No        |
 
+The regex that is used for naming is validating all package names from all package managers:
+
+```
+/\A\@?(([\w\-\.\+]*)\/)*([\w\-\.]+)@?(([\w\-\.\+]*)\/)*([\w\-\.]*)\z/
+```
+
+It allows for capital letters, while NPM does not, and allows for almost all of the
+characters NPM allows with a few exceptions (`~` is not allowed).
+
+NOTE: **Note:** Capital letters are needed because the scope is required to be
+identical to the top level namespace of the project. So, for example, if your
+project path is `My-Group/project-foo`, your package must be named `@My-Group/any-package-name`.
+`@my-group/any-package-name` will not work.
+
 CAUTION: **When updating the path of a user/group or transferring a (sub)group/project:**
 If you update the root namespace of a project with NPM packages, your changes will be rejected. To be allowed to do that, make sure to remove any NPM package first. Don't forget to update your `.npmrc` files to follow the above naming convention and run `npm publish` if necessary.
 
@@ -54,7 +68,7 @@ If a project is private or you want to upload an NPM package to GitLab,
 credentials will need to be provided for authentication. Support is available for [OAuth tokens](../../../api/oauth2.md#resource-owner-password-credentials-flow) or [personal access tokens](../../profile/personal_access_tokens.md).
 
 CAUTION: **2FA is only supported with personal access tokens:**
-If you have 2FA enabled, you need to use a [personal access token](../../profile/personal_access_tokens.md) with OAuth headers. Standard OAuth tokens won't be able to authenticate to the GitLab NPM Registry.
+If you have 2FA enabled, you need to use a [personal access token](../../profile/personal_access_tokens.md) with OAuth headers with the scope set to `api`. Standard OAuth tokens won't be able to authenticate to the GitLab NPM Registry.
 
 ### Authenticating with an OAuth token
 
@@ -108,7 +122,7 @@ Then, you could run `npm publish` either locally or via GitLab CI/CD:
 
 - **GitLab CI/CD:** Set an `NPM_TOKEN` [variable](../../../ci/variables/README.md)
   under your project's **Settings > CI/CD > Variables**.
-  
+
 ### Authenticating with a CI job token
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9104) in GitLab Premium 12.5.
@@ -116,7 +130,7 @@ Then, you could run `npm publish` either locally or via GitLab CI/CD:
 If you’re using NPM with GitLab CI/CD, a CI job token can be used instead of a personal access token.
 The token will inherit the permissions of the user that generates the pipeline.
 
-Add a corresponding section to your `.npmrc` file:  
+Add a corresponding section to your `.npmrc` file:
 
 ```ini
 @foo:registry=https://gitlab.com/api/v4/packages/npm/
@@ -156,9 +170,10 @@ a given scope, you will receive a `403 Forbidden!` error.
 
 ## Uploading a package with the same version twice
 
-If you upload a package with a same name and version twice, GitLab will show
-both packages in the UI, but the GitLab NPM Registry will expose the most recent
-one as it supports only one package per version for `npm install`.
+You cannot upload a package with the same name and version twice, unless you
+delete the existing package first. This aligns with npmjs.org's behavior, with
+the exception that npmjs.org does not allow users to ever publish the same version
+more than once, even if it has been deleted.
 
 ## Troubleshooting
 
@@ -211,3 +226,19 @@ And the `.npmrc` file should look like:
 //gitlab.com/api/v4/packages/npm/:_authToken=<your_oauth_token>
 @foo:registry=https://gitlab.com/api/v4/packages/npm/
 ```
+
+## NPM dependencies metadata
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/11867) in GitLab Premium 12.6.
+
+Starting from GitLab 12.6, new packages published to the GitLab NPM Registry expose the following attributes to the NPM client:
+
+- name
+- version
+- dist-tags
+- dependencies
+  - dependencies
+  - devDependencies
+  - bundleDependencies
+  - peerDependencies
+  - deprecated
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 70660e5e22f..9cbf4fd6192 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -5,7 +5,7 @@ description: 'Understand and explore the user permission levels in GitLab, and w
 # Permissions
 
 Users have different abilities depending on the access level they have in a
-particular group or project. If a user is both in a group's project and the
+particular group or project. If a user is both in a project's group and the
 project itself, the highest permission level is used.
 
 On public and internal projects the Guest role is not enforced. All users will
@@ -46,10 +46,11 @@ The following table depicts the various user permission levels in a project.
 | Download project                                  | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | Leave comments                                    | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View Insights charts **(ULTIMATE)**               | ✓       | ✓          | ✓           | ✓        | ✓      |
-| View approved/blacklisted licenses **(ULTIMATE)** | ✓       | ✓          | ✓           | ✓        | ✓      |
+| View approved/blacklisted licenses **(ULTIMATE)** | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View License Compliance reports **(ULTIMATE)**    | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View Security reports **(ULTIMATE)**              | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
 | View Dependency list **(ULTIMATE)**               | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
+| View License list **(ULTIMATE)**                  | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View licenses in Dependency list **(ULTIMATE)**   | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View [Design Management](project/issues/design_management.md) pages **(PREMIUM)** | ✓       | ✓          | ✓           | ✓        | ✓      |
 | View project code                                 | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
@@ -252,7 +253,7 @@ project and should only have access to that project.
 
 External users:
 
-- Cannot create groups or projects.
+- Cannot create groups, projects, or personal snippets.
 - Can only access projects to which they are explicitly granted access,
   thus hiding all other internal or private ones from them (like being
   logged out).
diff --git a/doc/user/profile/active_sessions.md b/doc/user/profile/active_sessions.md
index fe2eeebdb99..f68b11a57ec 100644
--- a/doc/user/profile/active_sessions.md
+++ b/doc/user/profile/active_sessions.md
@@ -2,10 +2,9 @@
 type: howto
 ---
 
-# Active Sessions
+# Active sessions
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17867)
->   in GitLab 10.8.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17867) in GitLab 10.8.
 
 GitLab lists all devices that have logged into your account. This allows you to
 review the sessions, and revoke any you don't recognize.
@@ -18,6 +17,13 @@ review the sessions, and revoke any you don't recognize.
 
 ![Active sessions list](img/active_sessions_list.png)
 
+## Active sessions limit
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31611) in GitLab 12.6.
+
+GitLab allows users to have up to 100 active sessions at once. If the number of active sessions
+exceeds 100, the oldest ones are deleted.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index c73368fbbd2..6a0377f118d 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -34,7 +34,7 @@ namespace.
 
 This service account will be:
 
-- Added to the installed Helm Tiller
+- Added to the installed Helm Tiller.
 - Used by Helm to install and run [GitLab managed applications](index.md#installing-applications).
 
 Helm will also create additional service accounts and other resources for each
@@ -111,6 +111,11 @@ If you don't want to use GitLab Runner in privileged mode, either:
 
 ## Add new cluster
 
+New clusters can be added using GitLab for:
+
+- Google Kubernetes Engine.
+- Amazon Elastic Kubernetes Service.
+
 ### GKE cluster
 
 GitLab supports:
@@ -206,46 +211,9 @@ GitLab supports:
 Before creating your first cluster on Amazon EKS with GitLab's integration,
 make sure the following requirements are met:
 
-- Enable the `create_eks_clusters` feature flag for your GitLab instance.
 - An [Amazon Web Services](https://aws.amazon.com/) account is set up and you are able to log in.
 - You have permissions to manage IAM resources.
 
-#### Enable the `create_eks_clusters` feature flag **(CORE ONLY)**
-
-NOTE: **Note:**
-If you are running a self-managed instance, EKS cluster creation will not be available
-unless the feature flag `create_eks_clusters` is enabled. This can be done from the Rails console
-by instance administrators.
-
-Use these commands to start the Rails console:
-
-```sh
-# Omnibus GitLab
-gitlab-rails console
-
-# Installation from source
-cd /home/git/gitlab
-sudo -u git -H bin/rails console RAILS_ENV=production
-```
-
-Then run the following command to enable the feature flag:
-
-```
-Feature.enable(:create_eks_clusters)
-```
-
-You can also enable the feature flag only for specific projects with:
-
-```
-Feature.enable(:create_eks_clusters, Project.find_by_full_path('my_group/my_project'))
-```
-
-Run the following command to disable the feature flag:
-
-```
-Feature.disable(:create_eks_clusters)
-```
-
 ##### Additional requirements for self-managed instances
 
 If you are using a self-managed GitLab instance, GitLab must first
@@ -332,6 +300,7 @@ new Kubernetes cluster to your project:
                       "iam:AttachRolePolicy",
                       "iam:CreateRole",
                       "iam:CreateInstanceProfile",
+                      "iam:CreateServiceLinkedRole",
                       "iam:GetRole",
                       "iam:ListRoles",
                       "iam:PassRole",
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index c5c2c2c07e7..6d863a8b888 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -128,9 +128,31 @@ automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.m
 need to explicitly provide the `KUBE_NAMESPACE` [deployment variable](#deployment-variables)
 that will be used by your deployment jobs, otherwise a namespace will be created for you.
 
-NOTE: **Note:**
-If you [install applications](#installing-applications) on your cluster, GitLab will create
-the resources required to run these even if you have chosen to manage your own cluster.
+#### Important notes
+
+Note the following with GitLab and clusters:
+
+- If you [install applications](#installing-applications) on your cluster, GitLab will
+  create the resources required to run these even if you have chosen to manage your own
+  cluster.
+- Be aware that manually managing resources that have been created by GitLab, like
+  namespaces and service accounts, can cause unexpected errors. If this occurs, try
+  [clearing the cluster cache](#clearing-the-cluster-cache).
+
+#### Clearing the cluster cache
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31759) in GitLab 12.6.
+
+If you choose to allow GitLab to manage your cluster for you, GitLab stores a cached
+version of the namespaces and service accounts it creates for your projects. If you
+modify these resources in your cluster manually, this cache can fall out of sync with
+your cluster, which can cause deployment jobs to fail.
+
+To clear the cache:
+
+1. Navigate to your project’s **Operations > Kubernetes** page, and select your cluster.
+1. Expand the **Advanced settings** section.
+1. Click **Clear cluster cache**.
 
 ### Base domain
 
diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md
index 2c16748a3ee..0b74f1e73eb 100644
--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -4,9 +4,20 @@ GitLab allows users to easily deploy AWS Lambda functions and create rich server
 
 GitLab supports deployment of functions to AWS Lambda using a combination of:
 
-- [Serverless Framework](https://serverless.com)
+- [Serverless Framework with AWS](https://serverless.com/framework/docs/providers/aws/)
 - GitLab CI/CD
 
+We have prepared an example with a step-by-step guide to create a simple function and deploy it on AWS.
+
+Additionally, in the [How To section](#how-to), you can read about different use cases,
+like:
+
+- Running a function locally.
+- Working with secrets.
+- Setting up CORS.
+
+Alternatively, you can quickly [create a new project with a template](https://docs.gitlab.com/ee/gitlab-basics/create-project.html#project-templates). The [`Serverless Framework/JS` template](https://gitlab.com/gitlab-org/project-templates/serverless-framework/) already includes all parts described below.
+
 ## Example
 
 In the following example, you will:
@@ -23,13 +34,13 @@ The example consists of the following steps:
 1. Crafting the `.gitlab-ci.yml` file
 1. Setting up your AWS credentials with your GitLab account
 1. Deploying your function
-1. Testing your function
+1. Testing the deployed function
 
 Lets take it step by step.
 
 ### Creating a Lambda handler function
 
-Your Lambda function will be the primary handler of requests. In this case we will create a very simple Node.js "Hello" function:
+Your Lambda function will be the primary handler of requests. In this case we will create a very simple Node.js `hello` function:
 
 ```javascript
 'use strict';
@@ -46,8 +57,6 @@ module.exports.hello = async event => {
     ),
   };
 };
-
-
 ```
 
 Place this code in the file `src/handler.js`.
@@ -58,7 +67,7 @@ In our case, `module.exports.hello` defines the `hello` handler that will be ref
 
 You can learn more about the AWS Lambda Node.js function handler and all its various options here: <https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html>
 
-### Creating a serverless.yml file
+### Creating a `serverless.yml` file
 
 In the root of your project, create a `serverless.yml` file that will contain configuration specifics for the Serverless Framework.
 
@@ -69,7 +78,7 @@ service: gitlab-example
 provider:
   name: aws
   runtime: nodejs10.x
-
+  
 functions:
   hello:
     handler: src/handler.hello
@@ -85,9 +94,9 @@ The `events` declaration will create a AWS API Gateway `GET` endpoint to receive
 
 You can read more about the available properties and additional configuration possibilities of the Serverless Framework here: <https://serverless.com/framework/docs/providers/aws/guide/serverless.yml/>
 
-### Crafting the .gitlab-ci.yml file
+### Crafting the `.gitlab-ci.yml` file
 
-In a `.gitlab-ci.yml` file, place the following code:
+In a `.gitlab-ci.yml` file in the root of your project, place the following code:
 
 ```yaml
 image: node:latest
@@ -109,21 +118,22 @@ This example code does the following:
 
 1. Uses the `node:latest` image for all GitLab CI builds
 1. The `deploy` stage:
-
-- Installs the `serverless framework`.
-- Deploys the serverless function to your AWS account using the AWS credentials defined above.
+   - Installs the Serverless Framework.
+   - Deploys the serverless function to your AWS account using the AWS credentials
+     defined above.
+   - Deploys the serverless function to your AWS account using the AWS credentials defined above
 
 ### Setting up your AWS credentials with your GitLab account
 
-In order to interact with your AWS account, the .gitlab-ci.yml requires both `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` be defined in your GitLab settings under **Settings > CI/CD > Variables**.
+In order to interact with your AWS account, the GitLab CI/CD pipelines require both `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be defined in your GitLab settings under **Settings > CI/CD > Variables**.
 For more information please see: <https://docs.gitlab.com/ee/ci/variables/README.html#via-the-ui>
 
 NOTE: **Note:**
-   The AWS credentials you provide must include IAM policies that provision correct access control to AWS Lambda, API Gateway, and CloudFormation resources.
+   The AWS credentials you provide must include IAM policies that provision correct access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
 
 ### Deploying your function
 
-Deploying your function is very simple, just `git push` to your GitLab repository and the GitLab build pipeline will automatically deploy your function.
+`git push` the changes to your GitLab repository and the GitLab build pipeline will automatically deploy your function.
 
 In your GitLab deploy stage log, there will be output containing your AWS Lambda endpoint URL.
 The log line will look similar to this:
@@ -133,7 +143,7 @@ endpoints:
   GET - https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello
 ```
 
-### Testing your function
+### Manually testing your function
 
 Running the following `curl` command should trigger your function.
 
@@ -144,7 +154,7 @@ NOTE: **Note:**
 curl https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello
 ```
 
-Should output:
+That should output:
 
 ```json
 {
@@ -156,8 +166,123 @@ Hooray! You now have a AWS Lambda function deployed via GitLab CI.
 
 Nice work!
 
-## Example code
+## How To
+
+In this section, we show you how to build on the basic example to:
+
+- Run the function locally.
+- Set up secret variables.
+- Set up CORS.
+
+### Running function locally
+
+The `serverless-offline` plugin allows to run your code locally. To run your code locally:
+
+1. Add the following to your `serverless.yml`:
+
+   ```yaml
+   plugins:
+     - serverless-offline
+   ```
+
+1. Start the service by running the following command:
+
+   ```shell
+   serverless offline
+   ```
+
+Running the following `curl` command should trigger your function.
+
+```sh
+curl http://localhost:3000/hello
+```
+
+It should output:
+
+```json
+{
+  "message": "Your function executed successfully!"
+}
+```
+
+### Secret variables
+
+Secrets are injected into your functions using environment variables.
+
+By defining variables in the provider section of the `serverless.yml`, you add them to
+the environment of the deployed function:
+
+```yaml
+provider:
+  ...
+  environment:
+    A_VARIABLE: ${env:A_VARIABLE}
+```
+
+From there, you can reference them in your functions as well.
+Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
+
+NOTE: **Note:**
+Anyone with access to the AWS environemnt may be able to see the values of those
+variables persisted in the lambda definition.
+
+### Setting up CORS
+
+If you want to set up a web page that makes calls to your function, like we have done in the [template](https://gitlab.com/gitlab-org/project-templates/serverless-framework/), you need to deal with the Cross-Origin Resource Sharing (CORS).
+
+The quick way to do that is to add the `cors: true` flag to the HTTP endpoint in your `serverless.yml`:
+
+```yaml
+functions:
+  hello:
+    handler: src/handler.hello
+    events:
+      - http: # Rewrite this part to enable CORS
+          path: hello
+          method: get
+          cors: true # <-- CORS here
+```
+
+You also need to return CORS specific headers in your function response:
+
+```javascript
+'use strict';
+
+module.exports.hello = async event => {
+  return {
+    statusCode: 200,
+    headers: {
+      // Uncomment the line below if you need access to cookies or authentication
+      // 'Access-Control-Allow-Credentials': true,
+      'Access-Control-Allow-Origin': '*'
+    },
+    body: JSON.stringify(
+      {
+        message: 'Your function executed successfully!'
+      },
+      null,
+      2
+    ),
+  };
+};
+```
+
+For more information, see the [Your CORS and API Gateway survival guide](https://serverless.com/blog/cors-api-gateway-survival-guide/)
+blog post written by the Serverless Framework team.
+
+### Writing automated tests
+
+The [Serverless Framework](https://gitlab.com/gitlab-org/project-templates/serverless-framework/)
+example project shows how to use Jest, Axios, and `serverless-offline` plugin to do
+automated testing of both local and deployed serverless function.
+
+## Examples and template
+
+The example code is available:
 
-To see the example code for this example please follow the link below:
+- As a [cloneable repository](https://gitlab.com/gitlab-org/serverless/examples/serverless-framework-js).
+- In a version with [tests and secret variables](https://gitlab.com/gitlab-org/project-templates/serverless-framework/).
 
-- [Node.js example](https://gitlab.com/gitlab-org/serverless/examples/serverless-framework-js): Deploy a AWS Lambda Javascript function + API Gateway using Serverless Framework and GitLab CI/CD
+You can also use a [template](https://docs.gitlab.com/ee/gitlab-basics/create-project.html#project-templates)
+(based on the version with tests and secret variables) from within the GitLab UI (see
+the `Serverless Framework/JS` template).
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index ffd7b0c0f2a..ae04dbab1a0 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -13,7 +13,7 @@ GitLab supports several ways deploy Serverless applications in both Kubernetes E
 
 Currently we support:
 
-- [Knative](#knative): Build Knative applications with Knative and gitlabktl on GKE.
+- [Knative](#knative): Build Knative applications with Knative and `gitlabktl` on GKE and EKS.
 - [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI.
 
 ## Knative
@@ -36,10 +36,12 @@ With GitLab Serverless, you can deploy both functions-as-a-service (FaaS) and se
 To run Knative on GitLab, you will need:
 
 1. **Existing GitLab project:** You will need a GitLab project to associate all resources. The simplest way to get started:
-
-   - If you are planning on deploying functions, clone the [functions example project](https://gitlab.com/knative-examples/functions) to get started.
-   - If you are planning on deploying a serverless application, clone the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started.
-
+   - If you are planning on [deploying functions](#deploying-functions),
+     clone the [functions example project](https://gitlab.com/knative-examples/functions) to get
+     started.
+   - If you are planning on [deploying a serverless application](#deploying-serverless-applications),
+     clone the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get
+     started.
 1. **Kubernetes Cluster:** An RBAC-enabled Kubernetes cluster is required to deploy Knative.
    The simplest way to get started is to add a cluster using [GitLab's GKE integration](../add_remove_clusters.md#gke-cluster).
    The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
@@ -58,7 +60,7 @@ To run Knative on GitLab, you will need:
 1. **`serverless.yml`** (for [functions only](#deploying-functions)): When using serverless to deploy functions, the `serverless.yml` file
    will contain the information for all the functions being hosted in the repository as well as a reference to the
    runtime being used.
-1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications): Knative requires a
+1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications)): Knative requires a
    `Dockerfile` in order to build your applications. It should be included at the root of your
    project's repo and expose port `8080`. `Dockerfile` is not require if you plan to build serverless functions
    using our [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes).
@@ -87,7 +89,7 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.
    for other platforms [Install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
 
 1. The Ingress is now available at this address and will route incoming requests to the proper service based on the DNS
-   name in the request. To support this, a wildcard DNS A record should be created for the desired domain name. For example,
+   name in the request. To support this, a wildcard DNS record should be created for the desired domain name. For example,
    if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info`
    pointing the ip address or hostname of the Ingress.
 
@@ -116,7 +118,8 @@ You must do the following:
 
 1. Ensure GitLab can manage Knative:
    - For a non-GitLab managed cluster, ensure that the service account for the token
-     provided can manage resources in the `serving.knative.dev` API group.
+     provided can manage resources in the `serving.knative.dev` API group. It will also
+     need list access to the deployments in the `knative-serving` namespace.
    - For a GitLab managed cluster, if you added the cluster in [GitLab 12.1 or later](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30235),
      then GitLab will already have the required access and you can proceed to the next step.
 
@@ -153,6 +156,19 @@ You must do the following:
        - delete
        - patch
        - watch
+     ---
+     apiVersion: rbac.authorization.k8s.io/v1
+     kind: ClusterRole
+     metadata:
+       name: gitlab-knative-version-role
+     rules:
+     - apiGroups:
+       - apps
+       resources:
+       - deployments
+       verbs:
+       - list
+       - get
      ```
 
      Then run the following command:
@@ -217,26 +233,40 @@ Or:
 
 ## Supported runtimes
 
-Serverless functions for GitLab can be written in 6 supported languages:
+Serverless functions for GitLab can be run using:
+
+- [GitLab-managed](#gitlab-managed-runtimes) runtimes.
+- [OpenFaaS](#openfaas-runtimes) runtimes.
 
-- NodeJS and Ruby, with GitLab-managed and OpenFaas runtimes.
-- C#, Go, PHP, and Python with OpenFaaS runtimes only.
+If a runtime is not available for the required programming language, consider deploying a
+[serverless application](#deploying-serverless-applications).
 
-### GitLab managed runtimes
+### GitLab-managed runtimes
 
-Currently the following [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes) are offered:
+Currently the following GitLab-managed [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes)
+are available:
 
-- ruby
-- node.js
-- Dockerfile
+- `go` (proof of concept)
+- `nodejs`
+- `ruby`
 
-`Dockerfile` presence is assumed when a runtime is not specified.
+You must provide a `Dockerfile` to run serverless functions if no runtime is specified.
 
 ### OpenFaaS runtimes
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/29253) in GitLab 12.5.
 
 [OpenFaaS classic runtimes](https://github.com/openfaas/templates#templates-in-store) can be used with GitLab serverless.
+
+OpenFaas runtimes are available for the following languages:
+
+- C#
+- Go
+- NodeJS
+- PHP
+- Python
+- Ruby
+
 Runtimes are specified using the pattern: `openfaas/classic/<template_name>`. The following
 example shows how to define a function in `serverless.yml` using an OpenFaaS runtime:
 
@@ -311,17 +341,21 @@ project):
 
    provider:
      name: triggermesh
-     environment:
+     envs:
        FOO: value
+     secrets:
+       - my-secrets
 
    functions:
      echo-js:
        handler: echo-js
        source: ./echo-js
-       runtime: https://gitlab.com/gitlab-org/serverless/runtimes/nodejs
+       runtime: gitlab/runtimes/nodejs
        description: "node.js runtime function"
-       environment:
+       envs:
          MY_FUNCTION: echo-js
+       secrets:
+         - my-secrets
    ```
 
 Explanation of the fields used above:
@@ -338,7 +372,8 @@ Explanation of the fields used above:
 | Parameter | Description |
 |-----------|-------------|
 | `name` | Indicates which provider is used to execute the `serverless.yml` file. In this case, the TriggerMesh middleware. |
-| `environment` | Includes the environment variables to be passed as part of function execution for **all** functions in the file, where `FOO` is the variable name and `BAR` are he variable contents. You may replace this with you own variables. |
+| `envs` | Includes the environment variables to be passed as part of function execution for **all** functions in the file, where `FOO` is the variable name and `BAR` are he variable contents. You may replace this with you own variables. |
+| `secrets` | Includes the contents of the Kubernetes secret as environment variables accessible to be passed as part of function execution for **all** functions in the file. The secrets are expected in ini format. |
 
 ### `functions`
 
@@ -349,9 +384,29 @@ subsequent lines contain the function attributes.
 |-----------|-------------|
 | `handler` | The function's name. |
 | `source` | Directory with sources of a functions. |
-| `runtime` (optional)| The runtime to be used to execute the function. When the runtime is not specified, we assume that `Dockerfile` is present in the function directory specified by `source`. |
+| `runtime` (optional)| The runtime to be used to execute the function. This can be a runtime alias (see [Runtime aliases](#runtime-aliases)), or it can be a full URL to a custom runtime repository. When the runtime is not specified, we assume that `Dockerfile` is present in the function directory specified by `source`. |
 | `description` | A short description of the function. |
-| `environment` | Sets an environment variable for the specific function only. |
+| `envs` | Sets an environment variable for the specific function only. |
+| `secrets` | Includes the contents of the Kubernetes secret as environment variables accessible to be passed as part of function execution for the specific function only. The secrets are expected in ini format. |
+
+### Deployment
+
+#### Runtime aliases
+
+The optional `runtime` parameter can refer to one of the following runtime aliases (also see [Supported runtimes](#supported-runtimes)):
+
+| Runtime alias | Maintained by |
+|-------------|---------------|
+| `gitlab/runtimes/go` | GitLab |
+| `gitlab/runtimes/nodejs` | GitLab |
+| `gitlab/runtimes/ruby` | GitLab |
+| `openfaas/classic/csharp` | OpenFaaS |
+| `openfaas/classic/go` | OpenFaaS |
+| `openfaas/classic/node` | OpenFaaS |
+| `openfaas/classic/php7` | OpenFaaS |
+| `openfaas/classic/python` | OpenFaaS |
+| `openfaas/classic/python3` | OpenFaaS |
+| `openfaas/classic/ruby` | OpenFaaS |
 
 After the `gitlab-ci.yml` template has been added and the `serverless.yml` file
 has been created, pushing a commit to your project will result in a CI pipeline
@@ -388,6 +443,33 @@ The sample function can now be triggered from any HTTP client using a simple `PO
 
      ![function execution](img/function-execution.png)
 
+### Secrets
+
+To access your Kubernetes secrets from within your function, the secrets should be created under the namespace of your serverless deployment.
+
+#### CLI example
+
+```bash
+kubectl create secret generic my-secrets -n "$KUBE_NAMESPACE" --from-literal MY_SECRET=imverysecure
+```
+
+#### Part of deployment job
+
+You can extend your `.gitlab-ci.yml` to create the secrets during deployment using the [environment variables](../../../../ci/variables/README.md)
+stored securely under your GitLab project.
+
+```yaml
+deploy:function:
+  stage: deploy
+  environment: production
+  extends: .serverless:deploy:functions
+  before_script:
+    - kubectl create secret generic my-secret
+        --from-literal MY_SECRET="$GITLAB_SECRET_VARIABLE"
+        --namespace "$KUBE_NAMESPACE"
+        --dry-run -o yaml | kubectl apply -f -
+```
+
 ### Running functions locally
 
 Running a function locally is a good way to quickly verify behavior during development.
@@ -427,9 +509,10 @@ To run a function locally:
 
 > Introduced in GitLab 11.5.
 
-Serverless applications are the building block of serverless functions. They are useful in scenarios where an existing
-runtime does not meet the needs of an application, such as one written in a language that has no runtime available. Note
-though that serverless applications should be stateless!
+Serverless applications are an alternative to [serverless functions](#deploying-functions).
+They are useful in scenarios where an existing runtime does not meet the needs of an application,
+such as one written in a language that has no runtime available. Note though that serverless
+applications should be stateless!
 
 NOTE: **Note:**
 You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started.
@@ -780,3 +863,23 @@ The instructions below relate to installing and running Certbot on a Linux serve
    After your changes are running on your Knative cluster, you can begin using the HTTPS protocol for secure access your deployed Knative services.
    In the event a mistake is made during this process and you need to update the cert, you will need to edit the gateway `knative-ingress-gateway`
    to switch back to `PASSTHROUGH` mode. Once corrections are made, edit the file again so the gateway will use the new certificates.
+
+## Using an older version of `gitlabktl`
+
+There may be situations where you want to run an older version of `gitlabktl`. This
+requires setting an older version of the `gitlabktl` image in the `.gitlab-ci.yml file.`
+
+To set an older version, add `image:` to the `functions:deploy` block. For example:
+
+```yaml
+functions:deploy:
+  extends: .serverless:deploy:functions
+  environment: production
+  image: registry.gitlab.com/gitlab-org/gitlabktl:0.5.0
+```
+
+Different versions are available by changing the version tag at the end of the registry URL in the
+format `registry.gitlab.com/gitlab-org/gitlabktl:<version>`.
+
+For a full inventory of available `gitlabktl` versions, see the `gitlabktl` project's
+[container registry](https://gitlab.com/gitlab-org/gitlabktl/container_registry).
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index b14d7f821bb..98e9188ed9b 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -14,7 +14,7 @@ With Deploy Boards you can gain more insight into deploys with benefits such as:
 
 - Following a deploy from the start, not just when it's done
 - Watching the rollout of a build across multiple servers
-- Finer state detail (Waiting, Deploying, Finished, Unknown)
+- Finer state detail (Succeeded, Running, Failed, Pending, Unknown)
 - See [Canary Deployments](canary_deployments.md)
 
 Here's an example of a Deploy Board of the production environment.
diff --git a/doc/user/project/img/service_desk_disabled.png b/doc/user/project/img/service_desk_disabled.png
index edae7e76986..ba11b508682 100644
--- a/doc/user/project/img/service_desk_disabled.png
+++ b/doc/user/project/img/service_desk_disabled.png
diff --git a/doc/user/project/img/service_desk_enabled.png b/doc/user/project/img/service_desk_enabled.png
index 9c143ff58cd..aee2b53a680 100644
--- a/doc/user/project/img/service_desk_enabled.png
+++ b/doc/user/project/img/service_desk_enabled.png
diff --git a/doc/user/project/import/gemnasium.md b/doc/user/project/import/gemnasium.md
index f1121745c7e..20614bf5cc5 100644
--- a/doc/user/project/import/gemnasium.md
+++ b/doc/user/project/import/gemnasium.md
@@ -98,7 +98,7 @@ back to both GitLab and GitHub when completed.
 
 1. The result of the job will be visible directly from the pipeline view:
 
-   ![Security Dashboard](../../application_security/security_dashboard/img/pipeline_security_dashboard_v12_3.png)
+   ![Security Dashboard](../../application_security/security_dashboard/img/pipeline_security_dashboard_v12_6.png)
 
 NOTE: **Note:**
 If you don't commit very often to your project, you may want to use
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index c173d3d3e11..29de700af4d 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -200,9 +200,14 @@ When [renaming a user](../profile/index.md#changing-your-username),
 
 ## Use your project as a Go package
 
-Any project can be used as a Go package including private projects in subgroups. To use packages
-hosted in private projects with the `go get` command, use a [`.netrc` file](https://ec.haxx.se/usingcurl-netrc.html)
-and a [personal access token](../profile/personal_access_tokens.md) in the password field.
+Any project can be used as a Go package including private projects in subgroups.
+GitLab responds correctly to `go get` and `godoc.org` discovery requests,
+including the [`go-import`](https://golang.org/cmd/go/#hdr-Remote_import_paths)
+and [`go-source`](https://github.com/golang/gddo/wiki/Source-Code-Links) meta
+tags, respectively. To use packages hosted in private projects with the `go get`
+command, use a [`.netrc` file](https://ec.haxx.se/usingcurl-netrc.html) and a
+[personal access token](../profile/personal_access_tokens.md) in the password
+field.
 
 For example:
 
diff --git a/doc/user/project/integrations/github.md b/doc/user/project/integrations/github.md
index 9d16748085c..b8b073af2a4 100644
--- a/doc/user/project/integrations/github.md
+++ b/doc/user/project/integrations/github.md
@@ -33,6 +33,9 @@ with `repo:status` access granted:
 1. Optionally uncheck **Static status check names** checkbox to disable static status check names.
 1. Save or optionally click "Test Settings".
 
+Once the integration is configured, see [Pipelines for external pull requests](../../../ci/ci_cd_for_external_repos/#pipelines-for-external-pull-requests)
+to configure pipelines to run for open pull requests.
+
 #### Static / dynamic status check names
 
 > - Introduced in GitLab 11.5: using static status check names as opt-in option.
diff --git a/doc/user/project/integrations/img/unify_circuit_configuration.png b/doc/user/project/integrations/img/unify_circuit_configuration.png
new file mode 100644
index 00000000000..285d4f92030
--- /dev/null
+++ b/doc/user/project/integrations/img/unify_circuit_configuration.png
diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md
index 874a1092b73..d08c8699eba 100644
--- a/doc/user/project/integrations/jira.md
+++ b/doc/user/project/integrations/jira.md
@@ -20,7 +20,7 @@ Here's how the integration responds when you take the following actions in GitLa
 - **Mention a Jira issue ID** in a commit message or MR (merge request).
   - GitLab hyperlinks to the Jira issue.
   - The Jira issue adds an issue link to the commit/MR in GitLab.
-  - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab.
+  - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab, unless this commenting to Jira is [disabled](#disabling-comments-on-jira-issues).
 - **Mention that a commit or MR 'closes', 'resolves', or 'fixes' a Jira issue ID**. When the commit is made on the project's default branch (usually master) or the change is merged to the default branch:
   - GitLab's merge request page displays a note that it "Closed" the Jira issue, with a link to the issue. (Note: Before the merge, an MR will display that it "Closes" the Jira issue.)
   - The Jira issue shows the activity and the Jira issue is closed, or otherwise transitioned.
@@ -95,6 +95,15 @@ with all Jira projects in your Jira instance and you'll see the Jira link on the
 
 ![Jira service page](img/jira_service_page_v12_2.png)
 
+### Disabling comments on Jira issues
+
+When you reference a Jira issue, it will always link back to the source commit/MR in GitLab, however, you can control whether GitLab will also cross-post a comment to the Jira issue. That functionality is enabled by default.
+
+To disable the automated commenting on Jira issues:
+
+1. Open the [Integrations page](project_services.md#accessing-the-project-services) and select **Jira**.
+1. In the **Event Action** section, uncheck **Comment**.
+
 ## Jira issues
 
 By now you should have [configured Jira](#configuring-jira) and enabled the
diff --git a/doc/user/project/integrations/project_services.md b/doc/user/project/integrations/project_services.md
index 315039f82b3..f960c59850d 100644
--- a/doc/user/project/integrations/project_services.md
+++ b/doc/user/project/integrations/project_services.md
@@ -54,6 +54,7 @@ Click on the service links to see further configuration instructions and details
 | [Prometheus](prometheus.md) | Monitor the performance of your deployed apps |
 | Pushover | Pushover makes it easy to get real-time notifications on your Android device, iPhone, iPad, and Desktop |
 | [Redmine](redmine.md) | Redmine issue tracker |
+| [Unify Circuit](unify_circuit.md) | Receive events notifications in Unify Circuit |
 | [YouTrack](youtrack.md) | YouTrack issue tracker |
 
 ## Push hooks limit
diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md
index d3d4afefb59..3b7309ea7e4 100644
--- a/doc/user/project/integrations/prometheus.md
+++ b/doc/user/project/integrations/prometheus.md
@@ -476,12 +476,12 @@ Prometheus server.
 
 > [Introduced][ce-29691] in GitLab 12.2.
 
-It is possible to display metrics charts within [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
+It is possible to display metrics charts within [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm). The maximum number of embeds allowed in a GitLab Flavored Markdown field is 100.
 
 NOTE: **Note:**
 Requires [Kubernetes](prometheus_library/kubernetes.md) metrics.
 
-To display a metric chart, include a link of the form `https://<root_url>/<project>/environments/<environment_id>/metrics`.
+To display a metric chart, include a link of the form `https://<root_url>/<project>/-/environments/<environment_id>/metrics`.
 
 A single chart may also be embedded. You can generate a link to the chart via the dropdown located on the right side of the chart:
 
@@ -520,7 +520,7 @@ The sharing dialog within Grafana provides the link, as highlighted below.
 NOTE: **Note:**
 For this embed to display correctly the Grafana instance must be available to the target user, either as a public dashboard or on the same network.
 
-Copy the link and add an image tag as [inline HTML](../../markdown.md#inline-html) in your markdown. You may tweak the query parameters as required. For instance, removing the `&from=` and `&to=` parameters will give you a live chart. Here is example markup for a live chart from GitLab's public dashboard:
+Copy the link and add an image tag as [inline HTML](../../markdown.md#inline-html) in your Markdown. You may tweak the query parameters as required. For instance, removing the `&from=` and `&to=` parameters will give you a live chart. Here is example markup for a live chart from GitLab's public dashboard:
 
 ```html
 <img src="https://dashboards.gitlab.com/render/d-solo/RZmbBr7mk/gitlab-triage?orgId=1&refresh=30s&var-env=gprd&var-environment=gprd&var-prometheus=prometheus-01-inf-gprd&var-prometheus_app=prometheus-app-01-inf-gprd&var-backend=All&var-type=All&var-stage=main&panelId=1247&width=1000&height=300"/>
@@ -534,7 +534,7 @@ This will render like so:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31376) in GitLab 12.5.
 
-Each project can support integration with one Grafana instance. This configuration allows a user to copy a link to a panel in Grafana, then paste it into a GitLab markdown field. The chart will be rendered in the GitLab chart format.
+Each project can support integration with one Grafana instance. This configuration allows a user to copy a link to a panel in Grafana, then paste it into a GitLab Markdown field. The chart will be rendered in the GitLab chart format.
 
 Prerequisites for embedding from a Grafana instance:
 
@@ -562,7 +562,7 @@ Prerequisites for embedding from a Grafana instance:
 1. If your Prometheus queries use Grafana's custom template variables, ensure that "Template variables" and "Current time range" options are toggled to **On**. Of Grafana global template variables, only `$__interval`, `$__from`, and `$__to` are currently supported.
    ![Grafana Sharing Dialog](img/grafana_sharing_dialog_v12_5.png)
 1. Click **Copy** to copy the URL to the clipboard.
-1. In GitLab, paste the URL into a markdown field and save. The chart will take a few moments to render.
+1. In GitLab, paste the URL into a Markdown field and save. The chart will take a few moments to render.
    ![GitLab Rendered Grafana Panel](img/rendered_grafana_embed_v12_5.png)
 
 ## Troubleshooting
@@ -574,6 +574,7 @@ If the "No data found" screen continues to appear, it could be due to:
   are not labeled correctly. To test this, connect to the Prometheus server and
   [run a query](prometheus_library/kubernetes.html#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG`
   with the name of your environment.
+- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics rake task](../../../administration/raketasks/maintenance.md#import-common-metrics).
 
 [autodeploy]: ../../../topics/autodevops/index.md#auto-deploy
 [kubernetes]: https://kubernetes.io
diff --git a/doc/user/project/integrations/prometheus_library/nginx.md b/doc/user/project/integrations/prometheus_library/nginx.md
index 3c6919561fd..cf46456ca42 100644
--- a/doc/user/project/integrations/prometheus_library/nginx.md
+++ b/doc/user/project/integrations/prometheus_library/nginx.md
@@ -22,7 +22,7 @@ NGINX server metrics are detected, which tracks the pages and content directly s
 
 To get started with NGINX monitoring, you should first enable the [VTS statistics](https://github.com/vozlt/nginx-module-vts)) module for your NGINX server. This will capture and display statistics in an HTML readable form. Next, you should install and configure the [NGINX VTS exporter](https://github.com/hnlq715/nginx-vts-exporter) which parses these statistics and translates them into a Prometheus monitoring endpoint.
 
-If you are using NGINX as your Kubernetes ingress, GitLab will [automatically detect](nginx_ingress.md) the metrics once enabled in 0.9.0 and later releases.
+If you are using NGINX as your Kubernetes Ingress, GitLab will [automatically detect](nginx_ingress.md) the metrics once enabled in 0.9.0 and later releases.
 
 ## Specifying the Environment label
 
diff --git a/doc/user/project/integrations/unify_circuit.md b/doc/user/project/integrations/unify_circuit.md
new file mode 100644
index 00000000000..e357afb9224
--- /dev/null
+++ b/doc/user/project/integrations/unify_circuit.md
@@ -0,0 +1,27 @@
+# Unify Circuit service
+
+The Unify Circuit service sends notifications from GitLab to the conversation for which the webhook was created.
+
+## On Unify Circuit
+
+1. Open the conversation in which you want to see the notifications.
+1. From the conversation menu, select **Configure Webhooks**.
+1. Click **ADD WEBHOOK** and fill in the name of the bot that will post the messages. Optionally define avatar.
+1. Click **SAVE** and copy the **Webhook URL** of your webhook.
+
+For more information, see the [Unify Circuit documentation for configuring incoming webhooks](https://www.circuit.com/unifyportalfaqdetail?articleId=164448).
+
+## On GitLab
+
+When you have the **Webhook URL** for your Unify Circuit conversation webhook, you can set up the GitLab service.
+
+1. Navigate to the [Integrations page](project_services.md#accessing-the-project-services) in your project's settings, i.e. **Project > Settings > Integrations**.
+1. Select the **Unify Circuit** project service to configure it.
+1. Check the **Active** checkbox to turn on the service.
+1. Check the checkboxes corresponding to the GitLab events you want to receive in Unify Circuit.
+1. Paste the **Webhook URL** that you copied from the Unify Circuit configuration step.
+1. Configure the remaining options and click `Save changes`.
+
+Your Unify Circuit conversation will now start receiving GitLab event notifications as configured.
+
+![Unify Circuit configuration](img/unify_circuit_configuration.png)
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index d0f538a4b52..bb946574371 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -47,6 +47,20 @@ and **per project and per group** for **GitLab Enterprise Edition**.
 Navigate to the webhooks page by going to your project's
 **Settings ➔ Integrations**.
 
+## Maximum number of webhooks (per tier)
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/20730) in GitLab 12.6.
+
+A maximum number of project webhooks applies to each [GitLab.com
+tier](https://about.gitlab.com/pricing/), as shown in the following table:
+
+| Tier     | Number of webhooks per project |
+|----------|--------------------------------|
+| Free     | 10                             |
+| Bronze   | 20                             |
+| Silver   | 30                             |
+| Gold     | 100                            |
+
 ## Use-cases
 
 - You can set up a webhook in GitLab to send a notification to
@@ -969,7 +983,7 @@ X-Gitlab-Event: Wiki Page Hook
     "http_url": "http://example.com/root/awesome-project.git"
   },
   "wiki": {
-    "web_url": "http://example.com/root/awesome-project/wikis/home",
+    "web_url": "http://example.com/root/awesome-project/-/wikis/home",
     "git_ssh_url": "git@example.com:root/awesome-project.wiki.git",
     "git_http_url": "http://example.com/root/awesome-project.wiki.git",
     "path_with_namespace": "root/awesome-project.wiki",
@@ -981,7 +995,7 @@ X-Gitlab-Event: Wiki Page Hook
     "format": "markdown",
     "message": "adding an awesome page to the wiki",
     "slug": "awesome",
-    "url": "http://example.com/root/awesome-project/wikis/awesome",
+    "url": "http://example.com/root/awesome-project/-/wikis/awesome",
     "action": "create"
   }
 }
@@ -1076,6 +1090,7 @@ X-Gitlab-Event: Pipeline Hook
          "finished_at": null,
          "when": "manual",
          "manual": true,
+         "allow_failure": false,
          "user":{
             "name": "Administrator",
             "username": "root",
@@ -1097,6 +1112,7 @@ X-Gitlab-Event: Pipeline Hook
          "finished_at": null,
          "when": "on_success",
          "manual": false,
+         "allow_failure": false,
          "user":{
             "name": "Administrator",
             "username": "root",
@@ -1123,6 +1139,7 @@ X-Gitlab-Event: Pipeline Hook
          "finished_at": "2016-08-12 15:26:29 UTC",
          "when": "on_success",
          "manual": false,
+         "allow_failure": false,
          "user":{
             "name": "Administrator",
             "username": "root",
@@ -1149,6 +1166,7 @@ X-Gitlab-Event: Pipeline Hook
          "finished_at": "2016-08-12 15:25:26 UTC",
          "when": "on_success",
          "manual": false,
+         "allow_failure": false,
          "user":{
             "name": "Administrator",
             "username": "root",
@@ -1175,6 +1193,7 @@ X-Gitlab-Event: Pipeline Hook
          "finished_at": null,
          "when": "on_success",
          "manual": false,
+         "allow_failure": false,
          "user":{
             "name": "Administrator",
             "username": "root",
@@ -1218,6 +1237,7 @@ X-Gitlab-Event: Job Hook
   "build_duration": null,
   "build_allow_failure": false,
   "build_failure_reason": "script_failure",
+  "pipeline_id": 2366,
   "project_id": 380,
   "project_name": "gitlab-org/gitlab-test",
   "user": {
@@ -1243,10 +1263,18 @@ X-Gitlab-Event: Job Hook
     "git_ssh_url": "git@192.168.64.1:gitlab-org/gitlab-test.git",
     "git_http_url": "http://192.168.64.1:3005/gitlab-org/gitlab-test.git",
     "visibility_level": 20
+  },
+  "runner": {
+    "active": true,
+    "is_shared": false,
+    "id": 380987,
+    "description": "shared-runners-manager-6.gitlab.com"
   }
 }
 ```
 
+Note that `commit.id` is the id of the pipeline, not the id of the commit.
+
 ## Image URL rewriting
 
 From GitLab 11.2, simple image references are rewritten to use an absolute URL
@@ -1271,7 +1299,7 @@ Markdown features, like link labels.
 
 ## Testing webhooks
 
-You can trigger the webhook manually. Sample data from the project will be used.Sample data will take from the project.
+You can trigger the webhook manually. Sample data from the project will be used. Sample data will take from the project.
 > For example: for triggering `Push Events` your project should have at least one commit.
 
 ![Webhook testing](img/webhook_testing.png)
diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md
index d8356abdd1c..e4264615488 100644
--- a/doc/user/project/labels.md
+++ b/doc/user/project/labels.md
@@ -12,7 +12,7 @@ requests are located.
 
 In GitLab, you can create project and group labels:
 
-- **Project labels** can be assigned to epics, issues and merge requests in that project only.
+- **Project labels** can be assigned to issues and merge requests in that project only.
 - **Group labels** can be assigned to any epics, issue and merge request in any project in
   that group, or any subgroups of the group.
 
diff --git a/doc/user/project/members/img/project_members.png b/doc/user/project/members/img/project_members.png
new file mode 100644
index 00000000000..5d44b5d957e
--- /dev/null
+++ b/doc/user/project/members/img/project_members.png
diff --git a/doc/user/project/members/img/project_members_filter_v12_6.png b/doc/user/project/members/img/project_members_filter_v12_6.png
new file mode 100644
index 00000000000..0207515ded0
--- /dev/null
+++ b/doc/user/project/members/img/project_members_filter_v12_6.png
diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md
index 2f8394eb104..c069882e38f 100644
--- a/doc/user/project/members/index.md
+++ b/doc/user/project/members/index.md
@@ -10,6 +10,31 @@ or import a new user to your project.
 To view, edit, add, and remove project's members, go to your
 project's **Settings > Members**.
 
+## Inherited membership
+
+When your project belongs to the group, group members inherit the membership and permission
+level for the project from the group.
+
+![Project members page](img/project_members.png)
+
+From the image above, we can deduce the following things:
+
+- There are 3 members that have access to the project.
+- User0 is a Reporter and has inherited their permissions from group `demo`
+  which contains current project.
+- For User1 there is no indication of a group, therefore they belong directly
+  to the project we're inspecting.
+- Administrator is the Owner and member of **all** groups and for that reason,
+  there is an indication of an ancestor group and inherited Owner permissions.
+
+[From](https://gitlab.com/gitlab-org/gitlab/issues/21727), you can filter this list
+using dropdown on the right side:
+
+![Project members filter](img/project_members_filter_v12_6.png)
+
+- **Show only direct members** displays only User1.
+- **Show only inherited members** displays User0 and Administrator.
+
 ## Add a user
 
 Right next to **People**, start typing the name or username of the user you
diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md
index 084ebf32a92..1dec58a8bb0 100644
--- a/doc/user/project/merge_requests/creating_merge_requests.md
+++ b/doc/user/project/merge_requests/creating_merge_requests.md
@@ -31,6 +31,8 @@ also appear in the top right of the:
 In this case, the merge request will use the most recent branch you pushed changes
 to as the source branch, and `master` in the current project as the target.
 
+You can also [create a new merge request directly from an issue](../repository/web_editor.md#create-a-new-branch-from-an-issue).
+
 ## Workflow for new merge requests
 
 On the **New Merge Request** page, you can start by filling in the title and description
diff --git a/doc/user/project/merge_requests/img/merge_request_tab_position_v12_6.png b/doc/user/project/merge_requests/img/merge_request_tab_position_v12_6.png
new file mode 100644
index 00000000000..9284e58f456
--- /dev/null
+++ b/doc/user/project/merge_requests/img/merge_request_tab_position_v12_6.png
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index 1ca8c882ac7..203a2949243 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -40,6 +40,40 @@ B. Consider you're a web developer writing a webpage for your company's website:
 1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
 1. Your production team [cherry picks](cherry_pick_changes.md) the merge commit into production
 
+## Overview
+
+Merge requests (aka "MRs") display a great deal of information about the changes proposed.
+The body of an MR contains its description, along with its widget (displaying information
+about CI/CD pipelines, when present), followed by the discussion threads of the people
+collaborating with that MR.
+
+MRs also contain navigation tabs from which you can see the discussion happening on the thread,
+the list of commits, the list of pipelines and jobs, the code changes and inline code reviews.
+
+## Merge request navigation tabs at the top
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/33813) in GitLab 12.6. This positioning is experimental.
+
+So far, the navigation tabs present in merge requests to display **Discussion**,
+**Commits**, **Pipelines**, and **Changes** were located after the merge request
+widget.
+
+To facilitate this navigation without having to scroll up and down through the page
+to find these tabs, based on user feedback, we are experimenting with a new positioning
+of these tabs. They are now located at the top of the merge request, with a new
+**Overview** tab, containing the description of the merge request followed by the
+widget. Next to **Overview**, you can find **Pipelines**, **Commits**, and **Changes**.
+
+![Merge request tab positions](img/merge_request_tab_position_v12_6.png)
+
+Please note this change is currently behind a feature flag which is enabled by default. For
+self-managed instances, it can be disabled through the Rails console by a GitLab
+administrator with the following command:
+
+```ruby
+Feature.disable(:mr_tabs_position)
+```
+
 ## Creating merge requests
 
 While making changes to files in the `master` branch of a repository is possible, it is not
diff --git a/doc/user/project/merge_requests/merge_request_dependencies.md b/doc/user/project/merge_requests/merge_request_dependencies.md
index c99e6663093..8b8aa30e75a 100644
--- a/doc/user/project/merge_requests/merge_request_dependencies.md
+++ b/doc/user/project/merge_requests/merge_request_dependencies.md
@@ -9,6 +9,8 @@ type: reference, concepts
 > - [Renamed](https://gitlab.com/gitlab-org/gitlab/merge_requests/17291) from
 "Cross-project dependencies" to "Merge Requests dependencies" in
 [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+> - Intra-project MR dependencies were [introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/16799)
+in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
 
 Merge request dependencies allows a required order of merging
 between merge requests to be expressed. If a merge request "depends on" another,
@@ -20,10 +22,6 @@ only enforced for the dependent merge request. A merge request in a **CORE** or
 **STARTER** project can be a dependency of a **PREMIUM** merge request, but not
 vice-versa.
 
-NOTE: **Note:**
-A merge request can only depend on merge requests in a different project. Two
-merge requests in the same project cannot depend on each other.
-
 ## Use cases
 
 - Ensure changes to a library are merged before changes to a project that
diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
index 6630179ea47..e1ac8b2183c 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -69,7 +69,7 @@ For example, to that on merge requests there is always a passing job even though
 
 ```yaml
 enable_merge:
-  only: merge_requests
+  only: [merge_requests]
   script:
     - echo true
 ```
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 f693b0b1e72..97c16a9794d 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
@@ -68,7 +68,7 @@ list.
 
 By default, the diff shows only the parts of a file which are changed.
 To view more unchanged lines above or below a change click on the
-**Expand up** or **Expand down** icons. You can also click on **Show all lines**
+**Expand up** or **Expand down** icons. You can also click on **Show unchanged lines**
 to expand the entire file.
 
 ![Incrementally expand merge request diffs](img/incrementally_expand_merge_request_diffs_v12_2.png)
diff --git a/doc/user/project/milestones/index.md b/doc/user/project/milestones/index.md
index 21a4e3d8ead..eacc1fd12dc 100644
--- a/doc/user/project/milestones/index.md
+++ b/doc/user/project/milestones/index.md
@@ -68,8 +68,8 @@ If you are expanding from a few projects to a larger number of projects within t
 
 From the project milestone list page, you can promote a project milestone to a group milestone. This will merge all project milestones across all projects in this group with the same name into a single group milestones. All issues and merge requests that previously were assigned one of these project milestones will now be assigned the new group milestones. This action cannot be reversed and the changes are permanent.
 
->**Note:**
-Not all features on the project milestone view are available on the group milestone view. If you promote a project milestone to a group milestone, you will lose these features. See [Milestone view](#milestone-view) to see which features are missing from the group milestone view.
+CAUTION: **Caution:**
+From GitLab 12.4 and earlier, some information is lost when you promote a project milestone to a group milestone. Not all features on the project milestone view are available on the group milestone view. If you promote a project milestone to a group milestone, you will lose these features. See [Milestone view](#milestone-view) to see which features are missing from the group milestone view.
 
 ![Promote milestone](img/milestones_promote_milestone.png)
 
@@ -105,14 +105,17 @@ The milestone view shows the title and description.
 
 There are also tabs below these that show the following:
 
-- Issues
-  Shows all issues assigned to the milestone. These are displayed in three columns: Unstarted issues, ongoing issues, and completed issues.
-- Merge requests
-  Shows all merge requests assigned to the milestone. These are displayed in four columns: Work in progress merge requests, waiting for merge, rejected, and closed.
-- Participants
-  Shows all assignees of issues assigned to the milestone.
-- Labels
-  Shows all labels that are used in issues assigned to the milestone.
+- **Issues**: Shows all issues assigned to the milestone. These are displayed in three columns named:
+  - Unstarted Issues (open and unassigned)
+  - Ongoing Issues (open and assigned)
+  - Completed Issues (closed)
+- **Merge Requests**: Shows all merge requests assigned to the milestone. These are displayed in four columns named:
+  - Work in progress (open and unassigned)
+  - Waiting for merge (open and unassigned)
+  - Rejected (closed)
+  - Merged
+- **Participants**: Shows all assignees of issues assigned to the milestone.
+- **Labels**: Shows all labels that are used in issues assigned to the milestone.
 
 ### Project Burndown Charts **(STARTER)**
 
diff --git a/doc/user/project/operations/error_tracking.md b/doc/user/project/operations/error_tracking.md
index 04eda026bc3..912d7fdbef5 100644
--- a/doc/user/project/operations/error_tracking.md
+++ b/doc/user/project/operations/error_tracking.md
@@ -32,7 +32,7 @@ GitLab provides an easy way to connect Sentry to your project:
 1. Click **Save changes** for the changes to take effect.
 1. You can now visit **Operations > Error Tracking** in your project's sidebar to [view a list](#error-tracking-list) of Sentry errors.
 
-### Enabling Gitlab issues links
+### Enabling GitLab issues links
 
 You may also want to enable Sentry's GitLab integration by following the steps in the [Sentry documentation](https://docs.sentry.io/workflow/integrations/global-integrations/#gitlab)
 
@@ -42,9 +42,9 @@ NOTE: **Note:**
 You will need at least Reporter [permissions](../../permissions.md) to view the Error Tracking list.
 
 The Error Tracking list may be found at **Operations > Error Tracking** in your project's sidebar.
-Errors can be filtered by title.
+Errors can be filtered by title or sorted by Frequency, First Seen or Last Seen. Errors are always sorted in descending order by the field specified.
 
-![Error Tracking list](img/error_tracking_list.png)
+![Error Tracking list](img/error_tracking_list_v12_6.png)
 
 ## Error Details
 
@@ -52,7 +52,13 @@ From error list, users can navigate to the error details page by clicking the ti
 
 This page has:
 
-- A link to Sentry issue.
-- A full stack trace along with other details.
+- A link to the Sentry issue.
+- Other details about the issue, including a full stack trace.
 
-![Error Details](img/error_details_v12_5.png)
+If the error has not been linked to an existing GitLab issue, a 'Create Issue' button will be visible:
+
+![Error Details without Issue Link](img/error_details_v12_6.png)
+
+If a link does exist, it will be shown in the details and the 'Create Issue' button will be hidden:
+
+![Error Details with Issue Link](img/error_details_with_issue_v12_6.png)
diff --git a/doc/user/project/operations/feature_flags.md b/doc/user/project/operations/feature_flags.md
index c05f8fa8bc4..723f9d69995 100644
--- a/doc/user/project/operations/feature_flags.md
+++ b/doc/user/project/operations/feature_flags.md
@@ -75,7 +75,7 @@ To define specs for each environment:
 1. Set the status and rollout strategy of the additional spec. This status and rollout strategy combination takes precedence over the default spec since we always use the most specific match available.
 1. Click **Create feature flag** or **Update feature flag**.
 
-![Feature flag specs list](img/specs_list.png)
+![Feature flag specs list](img/specs_list_v12_6.png)
 
 NOTE: **NOTE**
 We'd highly recommend you to use the [Environment](../../../ci/environments.md)
@@ -119,17 +119,15 @@ CAUTION: **Caution:**
 If this strategy is selected, then the Unleash client **must** be given a user
 ID for the feature to be enabled. See the [Ruby example](#ruby-application-example) below.
 
-### Target users strategy
+#### User IDs
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/8240) in GitLab 12.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/8240) in GitLab 12.2. [Updated](https://gitlab.com/gitlab-org/gitlab/issues/34363) to be defined per environment in GitLab 12.6.
 
 A feature flag may be enabled for a list of target users. It is implemented
 using the Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid)
 activation strategy.
 
-The feature will always be enabled for all users in the list across all environments even if the matching environment spec **Status** is disabled.
-
-![Feature flag target users](img/target_users_v12_2.png)
+User IDs should be a comma separated list of values. For example, `user@example.com, user2@example.com`, or `username1,username2,username3`, etc.
 
 CAUTION: **Caution:**
 The Unleash client **must** be given a user ID for the feature to be enabled for
diff --git a/doc/user/project/operations/img/error_details_v12_6.png b/doc/user/project/operations/img/error_details_v12_6.png
new file mode 100644
index 00000000000..b9152bd2c11
--- /dev/null
+++ b/doc/user/project/operations/img/error_details_v12_6.png
diff --git a/doc/user/project/operations/img/error_details_with_issue_v12_6.png b/doc/user/project/operations/img/error_details_with_issue_v12_6.png
new file mode 100644
index 00000000000..963b70bd1e4
--- /dev/null
+++ b/doc/user/project/operations/img/error_details_with_issue_v12_6.png
diff --git a/doc/user/project/operations/img/error_tracking_list.png b/doc/user/project/operations/img/error_tracking_list.png
deleted file mode 100644
index 79b464e021e..00000000000
--- a/doc/user/project/operations/img/error_tracking_list.png
+++ /dev/null
diff --git a/doc/user/project/operations/img/error_tracking_list_v12_6.png b/doc/user/project/operations/img/error_tracking_list_v12_6.png
new file mode 100644
index 00000000000..b99c83c14d3
--- /dev/null
+++ b/doc/user/project/operations/img/error_tracking_list_v12_6.png
diff --git a/doc/user/project/operations/img/specs_list.png b/doc/user/project/operations/img/specs_list.png
deleted file mode 100644
index 43d069c09ce..00000000000
--- a/doc/user/project/operations/img/specs_list.png
+++ /dev/null
diff --git a/doc/user/project/operations/img/specs_list_v12_6.png b/doc/user/project/operations/img/specs_list_v12_6.png
new file mode 100644
index 00000000000..ea429802a40
--- /dev/null
+++ b/doc/user/project/operations/img/specs_list_v12_6.png
diff --git a/doc/user/project/operations/img/target_users_v12_2.png b/doc/user/project/operations/img/target_users_v12_2.png
deleted file mode 100644
index c88d2b7be97..00000000000
--- a/doc/user/project/operations/img/target_users_v12_2.png
+++ /dev/null
diff --git a/doc/user/project/operations/index.md b/doc/user/project/operations/index.md
index 2da9c3e70cf..df7ce61525e 100644
--- a/doc/user/project/operations/index.md
+++ b/doc/user/project/operations/index.md
@@ -6,6 +6,7 @@ your applications:
 - Collect [Prometheus metrics](../integrations/prometheus_library/index.md).
 - Deploy to different [environments](../../../ci/environments.md).
 - Connect your project to a [Kubernetes cluster](../clusters/index.md).
+- Manage your infrastructure with [Infrastructure as Code](../../infrastructure/index.md) approaches.
 - Discover and view errors generated by your applications with [Error Tracking](error_tracking.md).
 - Create, toggle, and remove [Feature Flags](feature_flags.md). **(PREMIUM)**
 - [Trace](tracing.md) the performance and health of a deployed application. **(ULTIMATE)**
diff --git a/doc/user/project/pages/getting_started/fork_sample_project.md b/doc/user/project/pages/getting_started/fork_sample_project.md
index ac1a29ca2a0..9c58189e984 100644
--- a/doc/user/project/pages/getting_started/fork_sample_project.md
+++ b/doc/user/project/pages/getting_started/fork_sample_project.md
@@ -41,7 +41,7 @@ forking (copying) a [sample project from the most popular Static Site Generators
    and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your
    site to the server.
 1. Once the pipeline has finished successfully, find the link to visit your
-   website from your project's **Settings > Pages**. It can take aproximatelly
+   website from your project's **Settings > Pages**. It can take approximately
    30 minutes to be deployed.
 
 You can also take some **optional** further steps:
diff --git a/doc/user/project/pages/pages_access_control.md b/doc/user/project/pages/pages_access_control.md
index cd715c6e3b9..1d8119cfe87 100644
--- a/doc/user/project/pages/pages_access_control.md
+++ b/doc/user/project/pages/pages_access_control.md
@@ -11,7 +11,7 @@ You can enable Pages access control on your project, so that only
 [members of your project](../../permissions.md#project-members-permissions)
 (at least Guest) can access your website:
 
-1. Navigate to your project's **Settings > General > Permissions**.
+1. Navigate to your project's **Settings > General** and expand **Visibility, project features, permissions**.
 1. Toggle the **Pages** button to enable the access control.
 
    NOTE: **Note:**
diff --git a/doc/user/project/pipelines/job_artifacts.md b/doc/user/project/pipelines/job_artifacts.md
index 794c3030c6a..4ea46399635 100644
--- a/doc/user/project/pipelines/job_artifacts.md
+++ b/doc/user/project/pipelines/job_artifacts.md
@@ -103,8 +103,12 @@ It is possible to download the latest artifacts of a job via a well known URL
 so you can use it for scripting purposes.
 
 NOTE: **Note:**
-The latest artifacts are considered as the artifacts created by jobs in the
-latest pipeline that succeeded for the specific ref.
+The latest artifacts are created by jobs in the **most recent** successful pipeline
+for the specific ref. If you run two types of pipelines for the same ref, the latest
+artifact will be determined by timing. For example, if a branch pipeline created
+by merging a merge request runs at the same time as a scheduled pipeline, the
+latest artifact will be from the pipeline that completed most recently.
+
 Artifacts for other pipelines can be accessed with direct access to them.
 
 The structure of the URL to download the whole artifacts archive is the following:
diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md
index 6480c7e0af9..ca888c69b37 100644
--- a/doc/user/project/pipelines/settings.md
+++ b/doc/user/project/pipelines/settings.md
@@ -67,26 +67,46 @@ For information about setting a maximum artifact size for a project, see
 
 ## Custom CI configuration path
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12509) in GitLab 9.4.
+> - [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.
 
 By default we look for the `.gitlab-ci.yml` file in the project's root
-directory. If you require a different location **within** the repository,
-you can set a custom path that will be used to look up the configuration file,
-this path should be **relative** to the root.
+directory. If needed, you can specify an alternate path and file name, including locations outside the project.
 
-Here are some valid examples:
+To customize the path:
 
-- `.gitlab-ci.yml`
+1. Go to the project's **Settings > CI / CD**.
+1. Expand the **General pipelines** section.
+1. Provide a value in the **Custom CI configuration path** field.
+1. Click **Save changes**.
+
+If the CI configuration is stored within the repository in a non-default
+location, the path must be relative to the root directory. Examples of valid
+paths and file names include:
+
+- `.gitlab-ci.yml` (default)
 - `.my-custom-file.yml`
 - `my/path/.gitlab-ci.yml`
 - `my/path/.my-custom-file.yml`
 
-The path can be customized at a project level. To customize the path:
+If the CI configuration will be hosted on an external site, the URL link must end with `.yml`:
 
-1. Go to the project's **Settings > CI / CD**.
-1. Expand the **General pipelines** section.
-1. Provide a value in the **Custom CI configuration path** field.
-1. Click **Save changes**.
+- `http://example.com/generate/ci/config.yml`
+
+If the CI configuration will be hosted in a different project within GitLab, the path must be relative
+to the root directory in the other project, with the group and project name added to the end:
+
+- `.gitlab-ci.yml@mygroup/another-project`
+- `my/path/.my-custom-file.yml@mygroup/another-project`
+
+Hosting the configuration file in a separate project allows stricter control of the
+configuration file. For example:
+
+- Create a public project to host the configuration file.
+- Give write permissions on the project only to users who are allowed to edit the file.
+
+Other users and projects will be able to access the configuration file without being
+able to edit it.
 
 ## Test coverage parsing
 
@@ -132,6 +152,9 @@ Pipeline visibility is determined by:
 - Your current [user access level](../../permissions.md).
 - The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
 
+NOTE: **Note:**
+If the project visibility is set to **Private**, the [**Public pipelines** setting will have no effect](../../../ci/enable_or_disable_ci.md#per-project-user-setting).
+
 This also determines the visibility of these related features:
 
 - Job output logs
diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md
index 8952f845b96..11789f7d497 100644
--- a/doc/user/project/push_options.md
+++ b/doc/user/project/push_options.md
@@ -31,19 +31,25 @@ git push -o <push_option>
 
 ## Push options for GitLab CI/CD
 
-If the `ci.skip` push option is used, the commit will be pushed, but no [CI pipeline](../../ci/pipelines.md)
-will be created.
+You can use push options to skip a CI/CD pipeline, or pass environment variables.
 
-| Push option | Description |
-| ----------- | ----------- |
-| `ci.skip`   | Do not create a CI pipeline for the latest push. |
+| Push option                    | Description                                                                                 |
+| ------------------------------ | ------------------------------------------------------------------------------------------- |
+| `ci.skip`                      | Do not create a CI pipeline for the latest push.                                            |
+| `ci.variable="<name>=<value>"` | Provide [environment variables](../../ci/variables/README.md) to be used in a CI pipeline, if one is created due to the push. |
 
-For example:
+An example of using `ci.skip`:
 
 ```shell
 git push -o ci.skip
 ```
 
+An example of passing some environment variables for a pipeline:
+
+```shell
+git push -o ci.variable="MAX_RETRIES=10" -o ci.variable="MAX_TIME=600"
+```
+
 ## Push options for merge requests
 
 You can use Git push options to perform certain actions for merge requests at the same
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index 61bc66a6a69..97ae429a33f 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -8,9 +8,9 @@ Quick actions are textual shortcuts for common actions on issues, epics, merge r
 and commits that are usually done by clicking buttons or dropdowns in GitLab's UI.
 You can enter these commands while creating a new issue or merge request, or
 in comments of issues, epics, merge requests, and commits. Each command should be
-on a separate line in order to be properly detected and executed. Once executed,
+on a separate line in order to be properly detected and executed.
 
-> From [GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26672), an alert is displayed when a quick action is successfully applied.
+> From [GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26672), once an action is executed, an alert is displayed when a quick action is successfully applied.
 
 ## Quick Actions for issues, merge requests and epics
 
@@ -60,7 +60,7 @@ The following quick actions are applicable to descriptions, discussions and thre
 | `/remove_epic`                        | ✓     |               |      | Remove from epic **(ULTIMATE)** |
 | `/promote`                            | ✓     |               |      | Promote issue to epic **(ULTIMATE)** |
 | `/confidential`                       | ✓     |               |      | Make confidential |
-| `/duplicate <#issue>`                 | ✓     |               |      | Mark this issue as a duplicate of another issue |
+| `/duplicate <#issue>`                 | ✓     |               |      | Mark this issue as a duplicate of another issue and relate them for **(STARTER)** |
 | `/create_merge_request <branch name>` | ✓     |               |      | Create a new merge request starting from the current issue |
 | `/relate #issue1 #issue2`             | ✓     |               |      | Mark issues as related **(STARTER)** |
 | `/move <path/to/project>`             | ✓     |               |      | Move this issue to another project |
diff --git a/doc/user/project/releases/img/edit_release_page_v12_5.png b/doc/user/project/releases/img/edit_release_page_v12_6.png
index 8b9c502a2ef..8b9c502a2ef 100644
--- a/doc/user/project/releases/img/edit_release_page_v12_5.png
+++ b/doc/user/project/releases/img/edit_release_page_v12_6.png
diff --git a/doc/user/project/releases/img/release_edit_button_v12_5.png b/doc/user/project/releases/img/release_edit_button_v12_6.png
index f60b0ecb1be..f60b0ecb1be 100644
--- a/doc/user/project/releases/img/release_edit_button_v12_5.png
+++ b/doc/user/project/releases/img/release_edit_button_v12_6.png
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index 9b7b20be98f..58e028c89be 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -32,7 +32,7 @@ your users to quickly scan the differences between each one you publish.
 
 NOTE: **Note:**
 [Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) and
-Release descriptions are unrelated. Description supports [markdown](../../markdown.md).
+Release descriptions are unrelated. Description supports [Markdown](../../markdown.md).
 
 ### Release assets
 
@@ -92,17 +92,17 @@ project.
 
 ## Editing a release
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26016) in GitLab 12.5.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26016) in GitLab 12.6.
 
 To edit the details of a release, navigate to **Project overview > Releases** and click
 the edit button (pencil icon) in the top-right corner of the release you want to modify.
 
-![A release with an edit button](img/release_edit_button_v12_5.png)
+![A release with an edit button](img/release_edit_button_v12_6.png)
 
 This will bring you to the **Edit Release** page, from which you can
 change some of the release's details.
 
-![Edit release page](img/edit_release_page_v12_5.png)
+![Edit release page](img/edit_release_page_v12_6.png)
 
 Currently, it is only possible to edit the release title and notes.
 To change other release information, such as its tag, associated
@@ -126,7 +126,7 @@ following modal window will be then displayed, from which you can select **New r
 ## Add release notes to Git tags
 
 You can add release notes to any Git tag using the notes feature. Release notes
-behave like any other markdown form in GitLab so you can write text and
+behave like any other Markdown form in GitLab so you can write text and
 drag and drop files to it. Release notes are stored in GitLab's database.
 
 There are several ways to add release notes:
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index 8756760fe4b..4cf0e458a53 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -37,6 +37,10 @@ After the forking is done, you can start working on the newly created
 repository. There, you will have full [Owner](../../permissions.md)
 access, so you can set it up as you please.
 
+CAUTION: **CAUTION:**
+From GitLab 12.6 onwards, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
+in any way, the fork relationship with all its forks will be removed.
+
 ## Merging upstream
 
 Once you are ready to send your code back to the main project, you need
diff --git a/doc/user/project/repository/git_blame.md b/doc/user/project/repository/git_blame.md
new file mode 100644
index 00000000000..454b3f86df9
--- /dev/null
+++ b/doc/user/project/repository/git_blame.md
@@ -0,0 +1,50 @@
+---
+type: reference, howto
+description: "Documentation on Git file blame."
+---
+
+# Git file blame
+
+> [Introduced](https://git.sphere.ly/staff/publicgitlab/commit/39c657930625ddc3ac8a921f01ffc83acadce68f) in GitLab 2.5
+
+[Git blame](https://git-scm.com/docs/git-blame) provides more information
+about every line in a file, including the last modified time, author, and
+commit hash.
+
+You can find the **Blame** button with each file in a project.
+
+![File blame button](img/file_blame_button_v12_6.png "Blame button")
+
+When you select the **Blame** button, you'll see a screen with the
+noted information:
+
+![Git blame output](img/file_blame_output_v12_6.png "Blame button output")
+
+If you hover over a commit in the UI, you'll see a precise date and time
+for that commit.
+
+## Associated `git` command
+
+If you're running `git` from the command line, the equivalent command is
+`git blame <filename>`. For example, if you want to find `blame` information
+about a `README.md` file in the local directory, run the following command:
+
+```bash
+git blame README.md
+```
+
+You'll see output similar to the following, which includes the commit time
+in UTC format:
+
+```bash
+62e2353a (Achilleas Pipinellis     2019-07-11 14:52:18 +0300   1) [![build status](https://gitlab.com/gitlab-org/gitlab-docs/badges/master/build.svg)](https://gitlab.com/gitlab-com/gitlab-docs/commits/master)
+fb0fc7d6 (Achilleas Pipinellis     2016-11-07 22:21:22 +0100   2)
+^764ca75 (Connor Shea              2016-10-05 23:40:24 -0600   3) # GitLab Documentation
+^764ca75 (Connor Shea              2016-10-05 23:40:24 -0600   4)
+0e62ed6d (Mike Jang                2019-11-26 21:44:53 +0000   5) This project hosts the repository used to generate the GitLab
+0e62ed6d (Mike Jang                2019-11-26 21:44:53 +0000   6) documentation website and deployed to https://docs.gitlab.com. It uses the
+```
+
+## File blame through the API
+
+You can also get this information over the [Git file blame REST API](../../../api/repository_files.md#get-file-blame-from-repository).
diff --git a/doc/user/project/repository/git_history.md b/doc/user/project/repository/git_history.md
new file mode 100644
index 00000000000..9cd3d0d4ed0
--- /dev/null
+++ b/doc/user/project/repository/git_history.md
@@ -0,0 +1,67 @@
+---
+type: reference, howto
+description: "Documentation on Git file history."
+---
+
+# Git file history
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/blob/9ba1224867665844b117fa037e1465bb706b3685/app/controllers/commits_controller.rb) in GitLab 0.8.0
+
+Git file History provides information about the commit history associated
+with a file.
+
+You can find the **History** button with each file in a project.
+
+![File history button](img/file_history_button_v12_6.png "History button")
+
+When you select the **History** button, you'll see a screen with the
+noted information:
+
+![Git log output](img/file_history_output_v12_6.png "History button output")
+
+If you hover over a commit in the UI, you'll see a precise date and time
+that commit was last modified.
+
+## Associated `git` command
+
+If you're running `git` from the command line, the equivalent command
+is `git log <filename>`. For example, if you want to find `history`
+information about a `README.md` file in the local directory, run the
+following command:
+
+```bash
+git log README.md
+```
+
+You'll see output similar to the following, which includes the commit
+time in UTC format:
+
+```bash
+commit 0e62ed6d9f39fa9bedf7efc6edd628b137fa781a
+Author: Mike Jang <mjang@gitlab.com>
+Date:   Tue Nov 26 21:44:53 2019 +0000
+
+    Deemphasize GDK as a doc build tool
+
+commit 418879420b1e3a4662067bd07b64bb6988654697
+Author: Marcin Sedlak-Jakubowski <msedlakjakubowski@gitlab.com>
+Date:   Mon Nov 4 19:58:27 2019 +0100
+
+    Fix typo
+
+commit 21cc1fef11349417ed515557748369cfb235fc81
+Author: Jacques Erasmus <jerasmus@gitlab.com>
+Date:   Mon Oct 14 22:13:40 2019 +0000
+
+    Add support for modern JS
+
+    Added rollup to the project
+
+commit 2f5e895aebfa5678e51db303b97de56c51e3cebe
+Author: Achilleas Pipinellis <axil@gitlab.com>
+Date:   Fri Sep 13 14:03:01 2019 +0000
+
+    Remove gitlab-foss Git URLs as we don't need them anymore
+
+    [ci skip]
+```
diff --git a/doc/user/project/repository/img/file_blame_button_v12_6.png b/doc/user/project/repository/img/file_blame_button_v12_6.png
new file mode 100644
index 00000000000..b5a18e6726f
--- /dev/null
+++ b/doc/user/project/repository/img/file_blame_button_v12_6.png
diff --git a/doc/user/project/repository/img/file_blame_output_v12_6.png b/doc/user/project/repository/img/file_blame_output_v12_6.png
new file mode 100644
index 00000000000..4aca40353d5
--- /dev/null
+++ b/doc/user/project/repository/img/file_blame_output_v12_6.png
diff --git a/doc/user/project/repository/img/file_history_button_v12_6.png b/doc/user/project/repository/img/file_history_button_v12_6.png
new file mode 100644
index 00000000000..b5a18e6726f
--- /dev/null
+++ b/doc/user/project/repository/img/file_history_button_v12_6.png
diff --git a/doc/user/project/repository/img/file_history_output_v12_6.png b/doc/user/project/repository/img/file_history_output_v12_6.png
new file mode 100644
index 00000000000..9e9855203af
--- /dev/null
+++ b/doc/user/project/repository/img/file_history_output_v12_6.png
diff --git a/doc/user/project/repository/img/web_editor_new_branch_from_issue.png b/doc/user/project/repository/img/web_editor_new_branch_from_issue.png
deleted file mode 100644
index 4e156b8adc8..00000000000
--- a/doc/user/project/repository/img/web_editor_new_branch_from_issue.png
+++ /dev/null
diff --git a/doc/user/project/repository/img/web_editor_new_branch_from_issue_create_button_v12_6.png b/doc/user/project/repository/img/web_editor_new_branch_from_issue_create_button_v12_6.png
new file mode 100644
index 00000000000..f40cc187b46
--- /dev/null
+++ b/doc/user/project/repository/img/web_editor_new_branch_from_issue_create_button_v12_6.png
diff --git a/doc/user/project/repository/img/web_editor_new_branch_from_issue_v_12_6.png b/doc/user/project/repository/img/web_editor_new_branch_from_issue_v_12_6.png
new file mode 100644
index 00000000000..d5a92546d40
--- /dev/null
+++ b/doc/user/project/repository/img/web_editor_new_branch_from_issue_v_12_6.png
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index 5a6e011220c..fc422bb5aba 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -34,7 +34,7 @@ You can either use the user interface (UI), or connect your local computer
 with GitLab [through the command line](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project).
 
 To configure [GitLab CI/CD](../../../ci/README.md) to build, test, and deploy
-you code, add a file called [`.gitlab-ci.yml`](../../../ci/quick_start/README.md)
+your code, add a file called [`.gitlab-ci.yml`](../../../ci/quick_start/README.md)
 to your repository's root.
 
 **From the user interface:**
@@ -48,6 +48,8 @@ it's easier to do so [via GitLab UI](web_editor.md):
 - [File templates](web_editor.md#template-dropdowns)
 - [Create a directory](web_editor.md#create-a-directory)
 - [Start a merge request](web_editor.md#tips)
+- [Find file history](git_history.md)
+- [Identify changes by line (Git blame)](git_blame.md)
 
 **From the command line:**
 
diff --git a/doc/user/project/repository/repository_mirroring.md b/doc/user/project/repository/repository_mirroring.md
index a682983ab83..993c96d2ae4 100644
--- a/doc/user/project/repository/repository_mirroring.md
+++ b/doc/user/project/repository/repository_mirroring.md
@@ -143,6 +143,7 @@ Changes pushed to the upstream repository will be pulled into the GitLab reposit
 CAUTION: **Caution:**
 If you do manually update a branch in the GitLab repository, the branch will become diverged from
 upstream and GitLab will no longer automatically update this branch to prevent any changes from being lost.
+Also note that deleted branches and tags in the upstream repository will not be reflected in the GitLab repository.
 
 ### How it works
 
@@ -247,6 +248,10 @@ If you need to change the key at any time, you can remove and re-add the mirror
 to generate a new key. You'll have to update the other repository with the new
 key to keep the mirror running.
 
+NOTE: **Note:**
+The generated keys are stored in the GitLab database, not in the filesystem. Therefore,
+SSH public key authentication for mirrors cannot be used in a pre-receive hook.
+
 ### Overwrite diverged branches **(STARTER)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/4559) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.6.
@@ -362,6 +367,7 @@ proxy_push()
       branch=$(expr "$refname" : "refs/heads/\(.*\)")
 
       if [ "$whitelisted" = "$branch" ]; then
+        unset GIT_QUARANTINE_PATH # handle https://git-scm.com/docs/git-receive-pack#_quarantine_environment
         error="$(git push --quiet $TARGET_REPO $NEWREV:$REFNAME 2>&1)"
         fail=$?
 
@@ -396,6 +402,15 @@ else
 fi
 ```
 
+Note that this sample has a few limitations:
+
+- This example may not work verbatim for your use case and might need modification.
+  - It does not regard different types of authentication mechanisms for the mirror.
+  - It does not work with forced updates (rewriting history).
+  - Only branches that match the `whitelisted` patterns will be proxy pushed.
+- The script circumvents the Git hook quarantine environment because the update of `$TARGET_REPO`
+  is seen as a ref update and Git will complain about it.
+
 ### Mirroring with Perforce Helix via Git Fusion **(STARTER)**
 
 CAUTION: **Warning:**
diff --git a/doc/user/project/repository/web_editor.md b/doc/user/project/repository/web_editor.md
index 944720c3863..f41ff12d0a4 100644
--- a/doc/user/project/repository/web_editor.md
+++ b/doc/user/project/repository/web_editor.md
@@ -95,20 +95,31 @@ There are multiple ways to create a branch from GitLab's web interface.
 
 In case your development workflow dictates to have an issue for every merge
 request, you can quickly create a branch right on the issue page which will be
-tied with the issue itself. You can see a **New branch** button after the issue
-description, unless there is already a branch with the same name or a referenced
-merge request.
+tied with the issue itself. You can see a **Create merge request** dropdown
+below the issue description unless there is already a branch with the same
+name or a referenced merge request.
 
-![New Branch Button](img/web_editor_new_branch_from_issue.png)
+![Create Button](img/web_editor_new_branch_from_issue_create_button_v12_6.png)
 
-Once you click it, a new branch will be created that diverges from the default
+This dropdown contains the options **Create merge request and branch** and **Create branch**.
+
+![New Branch Button](img/web_editor_new_branch_from_issue_v_12_6.png)
+
+Once you choose one of these options, a new branch or branch and merge request
+will be created, based on the default
 branch of your project, by default `master`. The branch name will be based on
 the title of the issue and as a prefix, it will have its internal ID. Thus, the example
-screenshot above will yield a branch named
-`23177-add-support-for-rich-references-to-referables`.
-
-Since GitLab 9.0, when you click the `New branch` in an empty repository project, GitLab automatically creates the master branch, commits a blank `README.md` file to it and creates and redirects you to a new branch based on the issue title.
-If your [project is already configured with a deployment service][project-services-doc] (e.g. Kubernetes), GitLab takes one step further and prompts you to set up [auto deploy][auto-deploy-doc] by helping you create a `.gitlab-ci.yml` file.
+screenshot above will create a branch named
+`2-make-static-site-auto-deploy-and-serve`.
+
+When you click the **Create branch** button in an empty
+repository project, GitLab automatically creates a `master` branch, commits
+a blank `README.md` file to it, and creates and redirects you to a new branch
+based on the issue title.
+If your [project is already configured with a deployment service](../integrations/project_services.md),
+such as Kubernetes, GitLab takes one step further and prompts you to set up
+[auto deploy](../../../topics/autodevops/index.md#auto-deploy)
+by helping you create a `.gitlab-ci.yml` file.
 
 After the branch is created, you can edit files in the repository to fix
 the issue. When a merge request is created based on the newly created branch,
@@ -116,9 +127,6 @@ the description field will automatically display the [issue closing pattern](../
 `Closes #ID`, where `ID` the ID of the issue. This will close the issue once the
 merge request is merged.
 
-[project-services-doc]: ../integrations/project_services.md
-[auto-deploy-doc]: ../../../topics/autodevops/index.md#auto-deploy
-
 ### Create a new branch from a project's dashboard
 
 If you want to make changes to several files before creating a new merge
@@ -152,7 +160,7 @@ SHA. From a project's files page, choose **New tag** from the dropdown.
 
 Give the tag a name such as `v1.0.0`. Choose the branch or SHA from which you
 would like to create this new tag. You can optionally add a message and
-release notes. The release notes section supports markdown format and you can
+release notes. The release notes section supports Markdown format and you can
 also upload an attachment. Click **Create tag** and you will be taken to the tag
 list page.
 
diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md
index 0ca34c4ed02..fad4af7102a 100644
--- a/doc/user/project/service_desk.md
+++ b/doc/user/project/service_desk.md
@@ -55,9 +55,9 @@ you can skip the step 1 below; you only need to enable it per project.
 
 1. [Set up incoming email](../../administration/incoming_email.md#set-it-up) for the GitLab instance. This must
    support [email sub-addressing](../../administration/incoming_email.md#email-sub-addressing).
-1. Navigate to your project's **Settings** and scroll down to the **Service Desk**
+1. Navigate to your project's **Settings > General** and scroll down to the **Service Desk**
    section.
-1. If you have the correct access and an Premium license,
+1. If you have the correct access and a Premium license,
    you will see an option to set up Service Desk:
 
    ![Activate Service Desk option](img/service_desk_disabled.png)
@@ -79,6 +79,9 @@ you can skip the step 1 below; you only need to enable it per project.
    However the older format is still supported, allowing existing aliases
    or contacts to continue working._
 
+1. If you have [templates](description_templates.md) in your repository, then you can optionally
+   select one of these templates from the dropdown to append it to all Service Desk issues.
+
 1. Service Desk is now enabled for this project! You should be able to access it from your project's navigation **Issue submenu**:
 
    ![Service Desk Navigation Item](img/service_desk_nav_item.png)
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 2dc507901d0..2c7a24da8f9 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -18,7 +18,7 @@ Adjust your project's name, description, avatar, [default branch](../repository/
 
 ![general project settings](img/general_settings.png)
 
-The project description also partially supports [standard markdown](../../markdown.md#standard-markdown-and-extensions-in-gitlab). You can use [emphasis](../../markdown.md#emphasis), [links](../../markdown.md#links), and [line-breaks](../../markdown.md#line-breaks) to add more context to the project description.
+The project description also partially supports [standard Markdown](../../markdown.md#standard-markdown-and-extensions-in-gitlab). You can use [emphasis](../../markdown.md#emphasis), [links](../../markdown.md#links), and [line-breaks](../../markdown.md#line-breaks) to add more context to the project description.
 
 ### Sharing and permissions
 
@@ -26,6 +26,10 @@ Set up your project's access, [visibility](../../../public_access/public_access.
 
 ![projects sharing permissions](img/sharing_and_permissions_settings_v12_3.png)
 
+CAUTION: **Caution:**
+[Reducing a project's visibility level](../../../public_access/public_access.md#reducing-visibility)
+will remove the fork relationship between the project and any forked project.
+
 If Issues are disabled, or you can't access Issues because you're not a project member, then Labels and Milestones
 links will be missing from the sidebar UI.