Add latest changes from gitlab-org/gitlab@master

8 files changed, 162 insertions, 95 deletions

diff --git a/doc/user/admin_area/monitoring/background_migrations.md b/doc/user/admin_area/monitoring/background_migrations.md
index a68d7109429..50593959710 100644
--- a/doc/user/admin_area/monitoring/background_migrations.md
+++ b/doc/user/admin_area/monitoring/background_migrations.md
@@ -46,3 +46,36 @@ To disable it:
 ```ruby
 Feature.disable(:execute_batched_migrations_on_schedule)
 ```
+
+## Automatic batch size optimization **(FREE SELF)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60133) in GitLab 13.12.
+> - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/329511) in GitLab 13.12.
+> - Enabled on GitLab.com.
+> - Recommended for production use.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-automatic-batch-size-optimization). **(FREE SELF)**
+
+There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+Refer to this feature's version history for more details.
+
+To maximize throughput of batched background migrations (in terms of the number of tuples updated per time unit), batch sizes are automatically adjusted based on how long the previous batches took to complete.
+
+## Enable or disable automatic batch size optimization **(FREE SELF)**
+
+Automatic batch size optimization for Batched Background Migrations is under development but ready for production use.
+It is deployed behind a feature flag that is **enabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can opt to disable it.
+
+To enable it:
+
+```ruby
+Feature.enable(:optimize_batched_migrations)
+```
+
+To disable it:
+
+```ruby
+Feature.disable(:optimize_batched_migrations)
+```
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md
index dc3a8d68628..8511c919c14 100644
--- a/doc/user/application_security/api_fuzzing/index.md
+++ b/doc/user/application_security/api_fuzzing/index.md
@@ -111,13 +111,14 @@ To generate an API Fuzzing configuration snippet:
 
 ### OpenAPI Specification
 
-> Support for OpenAPI Specification v3 was
+> Support for OpenAPI Specification using YAML format was
+> [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330583) in GitLab 14.0.
+> Support for OpenAPI Specification v3.0 was
 > [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/228652) in GitLab 13.9.
 
-The [OpenAPI Specification](https://www.openapis.org/) (formerly the Swagger Specification) is an
-API description format for REST APIs. This section shows you how to configure API fuzzing by using
-an OpenAPI Specification to provide information about the target API to test. OpenAPI Specifications
-are provided as a file system resource or URL.
+The [OpenAPI Specification](https://www.openapis.org/) (formerly the Swagger Specification) is an API description format for REST APIs. 
+This section shows you how to configure API fuzzing using an OpenAPI Specification to provide information about the target API to test. 
+OpenAPI Specifications are provided as a file system resource or URL. Both JSON and YAML OpenAPI formats are supported.
 
 API fuzzing uses an OpenAPI document to generate the request body. When a request body is required,
 the body generation is limited to these body types:
diff --git a/doc/user/application_security/dast_api/index.md b/doc/user/application_security/dast_api/index.md
index 939a037a32d..5e47f545ef9 100644
--- a/doc/user/application_security/dast_api/index.md
+++ b/doc/user/application_security/dast_api/index.md
@@ -68,10 +68,12 @@ starting in GitLab 14.0, GitLab will not check your repository's root for config
 
 ### OpenAPI Specification
 
-The [OpenAPI Specification](https://www.openapis.org/) (formerly the Swagger Specification) is an
-API description format for REST APIs. This section shows you how to configure DAST API by using
-an OpenAPI specification to provide information about the target API to test. OpenAPI specifications
-are provided as a file system resource or URL.
+> Support for OpenAPI Specification using YAML format was
+> [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330583) in GitLab 14.0.
+
+The [OpenAPI Specification](https://www.openapis.org/) (formerly the Swagger Specification) is an API description format for REST APIs. 
+This section shows you how to configure API fuzzing using an OpenAPI Specification to provide information about the target API to test. 
+OpenAPI Specifications are provided as a file system resource or URL. Both JSON and YAML OpenAPI formats are supported.
 
 DAST API uses an OpenAPI document to generate the request body. When a request body is required,
 the body generation is limited to these body types:
diff --git a/doc/user/compliance/compliance_dashboard/index.md b/doc/user/compliance/compliance_dashboard/index.md
index 7d4d0da7062..21af6387f9d 100644
--- a/doc/user/compliance/compliance_dashboard/index.md
+++ b/doc/user/compliance/compliance_dashboard/index.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36524) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.8.
 
-The Compliance Dashboard gives you the ability to see a group's Merge Request activity
+The Compliance Dashboard gives you the ability to see a group's merge request activity
 by providing a high-level view for all projects in the group. For example, code approved
 for merging into production.
 
@@ -28,10 +28,10 @@ This feature is for people who care about the compliance status of projects with
 
 You can use the dashboard to:
 
-- Get an overview of the latest Merge Request for each project.
-- See if Merge Requests were approved and by whom.
-- See Merge Request authors.
-- See the latest [CI Pipeline](../../../ci/pipelines/index.md) result for each Merge Request.
+- Get an overview of the latest merge request for each project.
+- See if merge requests were approved and by whom.
+- See merge request authors.
+- See the latest [CI Pipeline](../../../ci/pipelines/index.md) result for each merge request.
 
 ## Permissions
 
@@ -42,25 +42,25 @@ You can use the dashboard to:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217939) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.3.
 
-We support a separation of duties policy between users who create and approve Merge Requests.
+We support a separation of duties policy between users who create and approve merge requests.
 The approval status column can help you identify violations of this policy.
 Our criteria for the separation of duties is as follows:
 
-- [A Merge Request author is **not** allowed to approve their Merge Request](../../project/merge_requests/approvals/settings.md#allowing-merge-request-authors-to-approve-their-own-merge-requests)
-- [A Merge Request committer is **not** allowed to approve a Merge Request they have added commits to](../../project/merge_requests/approvals/settings.md#prevent-approval-of-merge-requests-by-their-committers)
-- [The minimum number of approvals required to merge a Merge Request is **at least** two](../../project/merge_requests/approvals/rules.md)
+- [A merge request author is **not** allowed to approve their merge request](../../project/merge_requests/approvals/settings.md#prevent-authors-from-approving-their-own-work)
+- [A merge request committer is **not** allowed to approve a merge request they have added commits to](../../project/merge_requests/approvals/settings.md#prevent-committers-from-approving-their-own-work)
+- [The minimum number of approvals required to merge a merge request is **at least** two](../../project/merge_requests/approvals/rules.md)
 
-The "Approval status" column shows you, at a glance, whether a Merge Request is complying with the above.
+The "Approval status" column shows you, at a glance, whether a merge request is complying with the above.
 This column has four states:
 
 | State | Description |
 |:------|:------------|
-| Empty | The Merge Request approval status is unknown |
-| ![Failed](img/failed_icon_v13_3.png) | The Merge Request **does not** comply with any of the above criteria |
-| ![Warning](img/warning_icon_v13_3.png) | The Merge Request complies with **some** of the above criteria |
-| ![Success](img/success_icon_v13_3.png) | The Merge Request complies with **all** of the above criteria |
+| Empty | The merge request approval status is unknown |
+| ![Failed](img/failed_icon_v13_3.png) | The merge request **does not** comply with any of the above criteria |
+| ![Warning](img/warning_icon_v13_3.png) | The merge request complies with **some** of the above criteria |
+| ![Success](img/success_icon_v13_3.png) | The merge request complies with **all** of the above criteria |
 
-If you do not see the success icon in your Compliance dashboard; please review the above criteria for the Merge Requests
+If you do not see the success icon in your Compliance dashboard; please review the above criteria for the merge requests
 project to make sure it complies with the separation of duties described above.
 
 ## Chain of Custody report **(ULTIMATE)**
diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md
index 1f64eee033c..ac48e44da52 100644
--- a/doc/user/project/merge_requests/approvals/index.md
+++ b/doc/user/project/merge_requests/approvals/index.md
@@ -26,19 +26,20 @@ rules to define what types of users can approve work. Some examples of rules you
 
 - Users with specific permissions can always approve work.
 - [Code owners](../../code_owners.md) can approve work for files they own.
-- Users with specific permissions can approve work, even if they don't have merge rights
+- Users with specific permissions can approve work,
+  [even if they don't have merge rights](rules.md#merge-request-approval-segregation-of-duties)
   to the repository.
 - Users with specific permissions can be allowed or denied the ability
-  to override approval rules on a specific merge request.
+  to [override approval rules on a specific merge request](rules.md#edit-or-override-merge-request-approval-rules).
 
 You can also configure additional [settings for merge request approvals](settings.md)
 for more control of the level of oversight and security your project needs, including:
 
-- Prevent users from overriding a merge request approval rule.
-- Reset approvals when new code is pushed.
-- Allow (or disallow) authors and committers to approve their own merge requests.
-- Require password authentication when approving.
-- Require security team approval.
+- [Prevent users from overriding a merge request approval rule.](settings.md#prevent-overrides-of-default-approvals)
+- [Reset approvals when new code is pushed.](settings.md#reset-approvals-on-push)
+- Allow (or disallow) [authors and committers](settings.md) to approve their own merge requests.
+- [Require password authentication when approving.](settings.md#require-authentication-for-approvals)
+- [Require security team approval.](settings.md#security-approvals-in-merge-requests)
 
 You can configure your merge request approval rules and settings through the GitLab
 user interface or [with the API](../../../../api/merge_request_approvals.md).
@@ -63,10 +64,10 @@ such as merge conflicts, [pending discussions](../../../discussions/index.md#onl
 or a [failed CI/CD pipeline](../merge_when_pipeline_succeeds.md).
 
 To prevent merge request authors from approving their own merge requests,
-enable [**Prevent author approval**](settings.md#allowing-merge-request-authors-to-approve-their-own-merge-requests)
+enable [**Prevent author approval**](settings.md#prevent-authors-from-approving-their-own-work)
 in your project's settings.
 
-If you enable [approval rule overrides](settings.md#prevent-overriding-default-approvals),
+If you enable [approval rule overrides](settings.md#prevent-overrides-of-default-approvals),
 merge requests created before a change to default approval rules are not affected.
 The only exceptions are changes to the [target branch](rules.md#approvals-for-protected-branches)
 of the rule.
@@ -118,7 +119,7 @@ You can modify your external approval rules
 
 The lack of an external approval doesn't block the merging of a merge request.
 
-When [approval rule overrides](settings.md#prevent-overriding-default-approvals) are allowed,
+When [approval rule overrides](settings.md#prevent-overrides-of-default-approvals) are allowed,
 changes to default approval rules will **not** be applied to existing
 merge requests, except for changes to the [target branch](rules.md#approvals-for-protected-branches)
 of the rule.
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index 3e40936f887..32f0160771f 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -49,7 +49,7 @@ Users of GitLab Premium and higher tiers can create [additional approval rules](
 Your configuration for approval rule overrides determines if the new rule is applied
 to existing merge requests:
 
-- If [approval rule overrides](settings.md#prevent-overriding-default-approvals) are allowed,
+- If [approval rule overrides](settings.md#prevent-overrides-of-default-approvals) are allowed,
   changes to these default rules are not applied to existing merge requests, except for
   changes to the [target branch](#approvals-for-protected-branches) of the rule.
 - If approval rule overrides are not allowed, all changes to default rules
@@ -138,10 +138,10 @@ approve in these ways:
   counts as one approver, and not two.
 - Merge request authors do not count as eligible approvers on their own merge requests by default.
   To change this behavior, disable the
-  [**Prevent author approval**](settings.md#allowing-merge-request-authors-to-approve-their-own-merge-requests)
+  [**Prevent author approval**](settings.md#prevent-authors-from-approving-their-own-work)
   project setting.
 - Committers to merge requests can approve a merge request. To change this behavior, enable the
-  [**Prevent committers approval**](settings.md#prevent-approval-of-merge-requests-by-their-committers)
+  [**Prevent committers approval**](settings.md#prevent-committers-from-approving-their-own-work)
   project setting.
 
 ### Code owners as eligible approvers
@@ -200,7 +200,7 @@ on a merge request, you can either add or remove approvers:
    1. Add or remove your desired approval rules.
    1. Select **Save changes**.
 
-Administrators can change the [merge request approvals settings](settings.md#prevent-overriding-default-approvals)
+Administrators can change the [merge request approvals settings](settings.md#prevent-overrides-of-default-approvals)
 to prevent users from overriding approval rules for merge requests.
 
 ## Configure optional approval rules
diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md
index a21d74162ab..8769f6a7470 100644
--- a/doc/user/project/merge_requests/approvals/settings.md
+++ b/doc/user/project/merge_requests/approvals/settings.md
@@ -7,91 +7,119 @@ type: reference, concepts
 
 # Merge request approval settings
 
-The settings for merge request approvals are found by going to
-**Settings > General** and expanding **Merge request (MR) approvals**.
+You can configure the settings for [merge request approvals](index.md) to
+ensure the approval rules meet your use case. You can also configure
+[approval rules](rules.md), which define the number and type of users who must
+approve work before it's merged. Merge request approval settings define how
+those rules are applied as a merge request moves toward completion.
 
-## Prevent overriding default approvals
+## Edit merge request approval settings
 
-Regardless of the approval rules you choose for your project, users can edit them in every merge
-request, overriding the [rules you set as default](rules.md#add-an-approval-rule).
-To prevent that from happening:
+To view or edit merge request approval settings:
 
-1. Select the **Prevent users from modifying MR approval rules in merge requests.** checkbox.
-1. Click **Save changes**.
+1. Go to your project and select **Settings > General**.
+1. Expand **Merge request (MR) approvals**.
 
-### Resetting approvals on push
+In this section of general settings, you can configure the settings described
+on this page.
 
-You can force all approvals on a merge request to be removed when new commits are
-pushed to the source branch of the merge request. If disabled, approvals persist
-even if there are changes added to the merge request. To enable this feature:
+## Prevent overrides of default approvals
 
-1. Check the **Require new approvals when new commits are added to an MR.**
-   checkbox.
-1. Click **Save changes**.
+By default, users can override the approval rules you [create for a project](rules.md)
+on a per-merge request basis. If you don't want users to change approval rules
+on merge requests, you can disable this setting:
 
-NOTE:
-Approvals do not get reset when [rebasing a merge request](../fast_forward_merge.md)
-from the UI. However, approvals are reset if the target branch is changed.
+1. Go to your project and select **Settings > General**.
+1. Expand **Merge request (MR) approvals**.
+1. Select the **Prevent users from modifying MR approval rules in merge requests** checkbox.
+1. Select **Save changes**.
 
-### Allowing merge request authors to approve their own merge requests **(PREMIUM)**
+TODO This change affects all open merge requests.
+
+## Reset approvals on push
+
+By default, an approval on a merge request remains in place, even if you add more changes
+after the approval. If you want to remove all existing approvals on a merge request
+when more changes are added to it:
+
+1. Go to your project and select **Settings > General**.
+1. Expand **Merge request (MR) approvals**.
+1. Select the **Require new approvals when new commits are added to an MR** checkbox.
+1. Select **Save changes**.
+
+Approvals aren't reset when a merge request is [rebased from the UI](../fast_forward_merge.md)
+However, approvals are reset if the target branch is changed.
+
+## Prevent authors from approving their own work **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3349) in GitLab 11.3.
 > - Moved to GitLab Premium in 13.9.
 
-By default, projects are configured to prevent merge requests from being approved by
-their own authors. To change this setting:
+By default, the author of a merge request cannot approve it. To change this setting:
 
-1. Go to your project's **Settings > General**, expand **Merge request (MR) approvals**.
-1. Uncheck the **Prevent MR approval by the author.** checkbox.
-1. Click **Save changes**.
+1. Go to your project and select **Settings > General**.
+1. Expand **Merge request (MR) approvals**.
+1. Clear the **Prevent MR approval by the author** checkbox.
+1. Select **Save changes**.
 
-Note that users can edit the approval rules in every merge request and override pre-defined settings unless it's set [**not to allow** overrides](#prevent-overriding-default-approvals).
+Authors can edit the approval rule in an individual merge request and override
+this setting, unless you configure one of these options:
 
-You can prevent authors from approving their own merge requests
-[at the instance level](../../../admin_area/merge_requests_approvals.md). When enabled,
-this setting is disabled on the project level, and not editable.
+- [Prevent overrides of default approvals](#prevent-overrides-of-default-approvals) at
+  the project level.
+- *(Self-managed instances only)* Prevent overrides of default approvals
+  [at the instance level](../../../admin_area/merge_requests_approvals.md). When configured
+  at the instance level, you can't edit this setting at the project or individual
+  merge request levels.
 
-### Prevent approval of merge requests by their committers **(PREMIUM)**
+## Prevent committers from approving their own work **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10441) in GitLab 11.10.
 > - Moved to GitLab Premium in 13.9.
 
-You can prevent users who have committed to a merge request from approving it,
-though code authors can still approve. You can enable this feature
-[at the instance level](../../../admin_area/merge_requests_approvals.md), which
-disables changes to this feature at the project level. If you prefer to manage
-this feature at the project level, you can:
+By default, users who commit to a merge request can still approve it. At both
+the project level or [instance level](../../../admin_area/merge_requests_approvals.md)
+you can prevent committers from approving merge requests that are partially
+their own. To do this:
 
-1. Check the **Prevent MR approvals from users who make commits to the MR.** checkbox.
-   If this check box is disabled, this feature has been disabled
-   [at the instance level](../../../admin_area/merge_requests_approvals.md).
-1. Click **Save changes**.
+1. Go to your project and select **Settings > General**.
+1. Expand **Merge request (MR) approvals**.
+1. Select the **Prevent MR approvals from users who make commits to the MR** checkbox.
+   If this checkbox is cleared, an administrator has disabled it
+   [at the instance level](../../../admin_area/merge_requests_approvals.md), and
+   it can't be changed at the project level.
+1. Select **Save changes**.
 
-Read the official Git documentation for an explanation of the
-[differences between authors and committers](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History).
+Even with this configuration, [code owners](../../code_owners.md) who contribute
+to a merge request can approve merge requests that affect files they own.
 
-### Require authentication when approving a merge request
+To learn more about the [differences between authors and committers](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History),
+read the official Git documentation for an explanation.
+
+## Require authentication for approvals
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5981) in GitLab 12.0.
 > - Moved to GitLab Premium in 13.9.
 
-NOTE:
-To require authentication when approving a merge request, you must enable
-**Password authentication enabled for web interface** under [sign-in restrictions](../../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
-in the Admin Area.
-
-You can force the approver to enter a password in order to authenticate before adding
-the approval. This enables an Electronic Signature for approvals such as the one defined
-by [CFR Part 11](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11&showFR=1&subpartNode=21:1.0.1.1.8.3)).
-To enable this feature:
+You can force potential approvers to first authenticate with a password. This
+permission enables an electronic signature for approvals, such as the one defined by
+[Code of Federal Regulations (CFR) Part 11](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11&showFR=1&subpartNode=21:1.0.1.1.8.3)):
 
-1. Check the **Require user password for approvals.** checkbox.
-1. Click **Save changes**.
+1. Enable password authentication for the web interface, as described in the
+   [sign-in restrictions documentation](../../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
+1. Go to your project and select **Settings > General**.
+1. Expand **Merge request (MR) approvals**.
+1. Select the **Require user password for approvals** checkbox.
+1. Select **Save changes**.
 
 ## Security approvals in merge requests **(ULTIMATE)**
 
-Merge request approvals can be configured to require approval from a member
-of your security team when a vulnerability would be introduced by a merge request.
-
-For more information, see
+You can require that a member of your security team approves a merge request if a
+merge request could introduce a vulnerability. To learn more, see
 [Security approvals in merge requests](../../../application_security/index.md#security-approvals-in-merge-requests).
+
+## Related links
+
+- [Instance-level merge request approval settings](../../../admin_area/merge_requests_approvals.md)
+- [Compliance Dashboard](../../../compliance/compliance_dashboard/index.md)
+- [Merge request approvals API](../../../../api/merge_request_approvals.md)
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index d38ac78162d..d3177aa7585 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -77,7 +77,9 @@ The user running the pipeline in the project should at least have Reporter acces
 Example `.compliance-gitlab-ci.yml`
 
 ```yaml
-stages: # Allows compliance team to control the ordering and interweaving of stages/jobs
+# Allows compliance team to control the ordering and interweaving of stages/jobs.
+# Stages without jobs defined will remain hidden.
+stages: 
 - pre-compliance
 - build
 - test