Add latest changes from gitlab-org/gitlab@master

6 files changed, 112 insertions, 15 deletions

diff --git a/doc/api/merge_request_approvals.md b/doc/api/merge_request_approvals.md
index 5b8bad1d685..86bc56b7149 100644
--- a/doc/api/merge_request_approvals.md
+++ b/doc/api/merge_request_approvals.md
@@ -567,6 +567,91 @@ PUT /projects/:id/approvers
 }
 ```
 
+## External Project-level MR approvals **(ULTIMATE)**
+
+Configuration for approvals on a specific Merge Request which makes a call to an external HTTP resource.
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab 13.10.
+> - It's [deployed behind a feature flag](../user/feature_flags.md), disabled by default.
+> - It's disabled on GitLab.com.
+> - It's not recommended for production use.
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-external-project-level-mr-approvals). **(ULTIMATE SELF)**
+
+### Get project external approval rules **(ULTIMATE)**
+
+You can request information about a project's external approval rules using the following endpoint:
+
+```plaintext
+GET /projects/:id/external_approval_rules
+```
+
+**Parameters:**
+
+| Attribute           | Type    | Required | Description         |
+|---------------------|---------|----------|---------------------|
+| `id`                | integer | yes      | The ID of a project |
+
+```json
+[
+  {
+    "id": 1,
+    "name": "Compliance Check",
+    "project_id": 6,
+    "external_url": "https://gitlab.com/example/test.json",
+    "protected_branches": [
+      {
+        "id": 14,
+        "project_id": 6,
+        "name": "master",
+        "created_at": "2020-10-12T14:04:50.787Z",
+        "updated_at": "2020-10-12T14:04:50.787Z",
+        "code_owner_approval_required": false
+      }
+    ]
+  }
+]
+```
+
+### Create external approval rule **(ULTIMATE)**
+
+You can create a new external approval rule for a project using the following endpoint:
+
+```plaintext
+POST /projects/:id/external_approval_rules
+```
+
+| Attribute              | Type           | Required | Description                                        |
+|------------------------|----------------|----------|----------------------------------------------------|
+| `id`                   | integer        | yes      | The ID of a project                                |
+| `name`                 | string         | yes      | Display name of approval rule                      |
+| `external_url`         | string         | yes      | URL of external approval resource                  |
+| `protected_branch_ids` | array<Integer> | no       | The ids of protected branches to scope the rule by |
+
+### Enable or disable External Project-level MR approvals **(ULTIMATE SELF)**
+
+Enable or disable External Project-level MR approvals is under development and not ready for production use. It is
+deployed behind a feature flag that is **disabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../user/feature_flags.md)
+can enable it.
+
+To enable it:
+
+```ruby
+# For the instance
+Feature.enable(:ff_compliance_approval_gates)
+# For a single project
+Feature.enable(:ff_compliance_approval_gates, Project.find(<project id>))
+```
+
+To disable it:
+
+```ruby
+# For the instance
+Feature.disable(:ff_compliance_approval_gates)
+# For a single project
+Feature.disable(:ff_compliance_approval_gates, Project.find(<project id>))
+```
+
 ## Merge Request-level MR approvals
 
 Configuration for approvals on a specific Merge Request. Must be authenticated for all endpoints.
diff --git a/doc/ci/metrics_reports.md b/doc/ci/metrics_reports.md
index 3966e5e3e89..716959143ef 100644
--- a/doc/ci/metrics_reports.md
+++ b/doc/ci/metrics_reports.md
@@ -26,12 +26,14 @@ Consider the following examples of data that can use Metrics Reports:
 
 ## How it works
 
-Metrics are read from the metrics report (default: `metrics.txt`). They are parsed and displayed in the MR widget.
+Metrics for a branch are read from the latest metrics report artifact (default filename: `metrics.txt`) as string values.
 
-All values are considered strings and string compare is used to find differences between the latest available `metrics` artifact from:
+For an MR, the values of these metrics from the feature branch are compared to the values from the target branch. Then they are displayed in the MR widget in this order:
 
-- `master`
-- The feature branch
+- Metrics that have been added by the MR. Marked with a **New** badge.
+- Existing metrics with changed values.
+- Existing metrics with unchanged values.
+- Metrics that have been removed by the MR. Marked with a **Removed** badge.
 
 ## How to set it up
 
diff --git a/doc/development/usage_ping/metrics_dictionary.md b/doc/development/usage_ping/metrics_dictionary.md
index 9f98671050c..f27e258a9c2 100644
--- a/doc/development/usage_ping/metrics_dictionary.md
+++ b/doc/development/usage_ping/metrics_dictionary.md
@@ -33,7 +33,7 @@ Each metric is defined in a separate YAML file consisting of a number of fields:
 | `product_group`     | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the metric. |
 | `product_category`  | no       | The [product category](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml) for the metric. |
 | `value_type`        | yes      | `string`; one of `string`, `number`, `boolean`.                                                               |
-| `status`            | yes      | `string`; status of the metric, may be set to `data_available`, `implemented`. |
+| `status`            | yes      | `string`; status of the metric, may be set to `data_available`, `planned`, `in_progress`, `implemented`, `not_used`, `deprecated` |
 | `time_frame`        | yes      | `string`; may be set to a value like `7d`, `28d`, `all`, `none`. |
 | `data_source`       | yes      | `string`: may be set to a value like `database`, `redis`, `redis_hll`, `prometheus`, `ruby`. |
 | `distribution`      | yes      | The [distribution](https://about.gitlab.com/handbook/marketing/strategic-marketing/tiers/#definitions) where the metric applies. |
diff --git a/doc/integration/bitbucket.md b/doc/integration/bitbucket.md
index 54bcaee7cab..a492b891248 100644
--- a/doc/integration/bitbucket.md
+++ b/doc/integration/bitbucket.md
@@ -26,6 +26,11 @@ To enable the Bitbucket OmniAuth provider you must register your application
 with Bitbucket.org. Bitbucket generates an application ID and secret key for
 you to use.
 
+WARNING:
+To help prevent an [OAuth 2 covert redirect](https://oauth.net/advisories/2014-1-covert-redirect/)
+vulnerability in which users' GitLab accounts could be compromised, append `/users/auth`
+to the end of the Bitbucket authorization callback URL.
+
 1. Sign in to [Bitbucket.org](https://bitbucket.org).
 1. Navigate to your individual user settings (**Bitbucket settings**) or a team's
    settings (**Manage team**), depending on how you want the application registered.
@@ -40,9 +45,7 @@ you to use.
    - **Application description:** *(Optional)* Fill this in if you wish.
    - **Callback URL:** (Required in GitLab versions 8.15 and greater)
      The URL to your GitLab installation, such as
-     `https://gitlab.example.com/users/auth`. Be sure to append `/users/auth` to
-     the end of the callback URL to prevent an
-     [OAuth2 convert redirect](http://tetraph.com/covert_redirect/) vulnerability.
+     `https://gitlab.example.com/users/auth`.
      Leaving this field empty
      [results in an `Invalid redirect_uri` message](https://confluence.atlassian.com/bitbucket/oauth-faq-338365710.html).
    - **URL:** The URL to your GitLab installation, such as `https://gitlab.example.com`.
diff --git a/doc/integration/github.md b/doc/integration/github.md
index 4258b1c3c76..4d8adfe42f1 100644
--- a/doc/integration/github.md
+++ b/doc/integration/github.md
@@ -10,6 +10,16 @@ You can integrate your GitLab instance with GitHub.com and GitHub Enterprise. Th
 enables users to import projects from GitHub, or sign in to your GitLab instance
 with their GitHub account.
 
+## Security check
+
+Some integrations risk compromising GitLab accounts. To help mitigate this
+[OAuth 2 covert redirect](https://oauth.net/advisories/2014-1-covert-redirect/)
+vulnerability, append `/users/auth` to the end of the authorization callback URL.
+
+However, as far as we know, GitHub does not validate the subdomain part of the `redirect_uri`.
+This means that a subdomain takeover, an XSS, or an open redirect on any subdomain of
+your website could enable the covert redirect attack.
+
 ## Enabling GitHub OAuth
 
 To enable the GitHub OmniAuth provider, you need an OAuth 2 Client ID and Client Secret from GitHub. To get these credentials, sign into GitHub and follow their procedure for [Creating an OAuth App](https://docs.github.com/en/developers/apps/creating-an-oauth-app).
@@ -19,9 +29,6 @@ When you create an OAuth 2 app in GitHub, you need the following information:
 - The URL of your GitLab instance, such as `https://gitlab.example.com`.
 - The authorization callback URL; in this case, `https://gitlab.example.com/users/auth`. Include the port number if your GitLab instance uses a non-default port.
 
-NOTE:
-To prevent an [OAuth2 covert redirect](https://oauth.net/advisories/2014-1-covert-redirect/) vulnerability, append `/users/auth` to the end of the GitHub authorization callback URL.
-
 See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
 After you have configured the GitHub provider, you need the following information. You must substitute that information in the GitLab configuration file in these next steps.
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 4bd0bddfd7d..e8dadd88147 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Auto DevOps **(FREE)**
 
-> - Generally available on GitLab 11.0.
+> - Introduced in GitLab 11.0 for general availability.
 
 GitLab Auto DevOps helps to reduce the complexity of software delivery by
 setting up pipelines and integrations for you. Instead of requiring you to
@@ -38,7 +38,7 @@ For a developer's guide, read [Auto DevOps development guide](../../development/
 
 ## Enabled by default
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3.
 
 On self-managed instances, Auto DevOps is enabled by default for all projects.
 It attempts to run on all pipelines in each project. An instance administrator can
@@ -205,7 +205,7 @@ After enabling the feature, an Auto DevOps pipeline is triggered on the `master`
 
 ### At the group level
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) in GitLab 11.10.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) in GitLab 11.10.
 
 Only administrators and group owners can enable or disable Auto DevOps at the group level.
 
@@ -232,7 +232,7 @@ Auto DevOps at the group and project level, respectively.
 
 ### Deployment strategy
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
 
 You can change the deployment strategy used by Auto DevOps by visiting your
 project's **Settings > CI/CD > Auto DevOps**. The following options