Add latest changes from gitlab-org/gitlab@14-9-stable-eev14.9.0-rc42

6 files changed, 17 insertions, 70 deletions

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 1d982196228..2f30298644a 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -178,14 +178,9 @@ nginx['client_max_body_size'] = "200m"
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/296669) in GitLab 13.9.
 > - It's deployed behind a feature flag, 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](../../../security/two_factor_authentication.md#enable-or-disable-2fa-for-git-operations).
 
-NOTE:
-This feature is under development and not ready for production use. It is deployed
-behind a feature flag that is **disabled by default**. To use it in GitLab
-self-managed instances, ask a GitLab administrator to [enable it](../../../security/two_factor_authentication.md#enable-or-disable-2fa-for-git-operations).
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. This feature is not ready for production use. This feature flag also affects [2FA for Git over SSH operations](../../../security/two_factor_authentication.md#2fa-for-git-over-ssh-operations).
 
 GitLab administrators can choose to customize the session duration (in minutes) for Git operations when 2FA is enabled. The default is 15 and this can be set to a value between 1 and 10080.
 
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 18379471bcf..0330d89aedc 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -55,31 +55,28 @@ can be set at:
 - The instance level.
 - [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/21688), the project and group level.
 
-The value is:
+For the setting on GitLab.com, see [Artifacts maximum size](../../gitlab_com/index.md#gitlab-cicd).
 
-- In *MB* and the default is 100MB per job.
-- [Set to 1G](../../gitlab_com/index.md#gitlab-cicd) on GitLab.com.
-
-To change it at the:
+The value is in MB and the default is 100MB per job. To change it at the:
 
 - Instance level:
 
   1. On the top bar, select **Menu > Admin**.
   1. On the left sidebar, select **Settings > CI/CD**.
   1. Change the value of maximum artifacts size (in MB).
-  1. Click **Save changes** for the changes to take effect.
+  1. Select **Save changes** for the changes to take effect.
 
 - Group level (this overrides the instance setting):
 
   1. Go to the group's **Settings > CI/CD > General Pipelines**.
   1. Change the value of **maximum artifacts size (in MB)**.
-  1. Click **Save changes** for the changes to take effect.
+  1. Select **Save changes** for the changes to take effect.
 
 - Project level (this overrides the instance and group settings):
 
   1. Go to the project's **Settings > CI/CD > General Pipelines**.
   1. Change the value of **maximum artifacts size (in MB)**.
-  1. Click **Save changes** for the changes to take effect.
+  1. Select **Save changes** for the changes to take effect.
 
 NOTE:
 The setting at all levels is only available to GitLab administrators.
@@ -94,7 +91,7 @@ and the default value is `30 days`.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Change the value of default expiration time.
-1. Click **Save changes** for the changes to take effect.
+1. Select **Save changes** for the changes to take effect.
 
 This setting is set per job and can be overridden in
 [`.gitlab-ci.yml`](../../../ci/yaml/index.md#artifactsexpire_in).
@@ -126,7 +123,7 @@ To disable the setting:
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand **Continuous Integration and Deployment**.
 1. Clear the **Keep the latest artifacts for all jobs in the latest successful pipelines** checkbox.
-1. Click **Save changes**
+1. Select **Save changes**
 
 When you disable the feature, the latest artifacts do not immediately expire.
 A new pipeline must run before the latest artifacts can expire and be deleted.
@@ -156,7 +153,7 @@ After that time passes, the jobs are archived and no longer able to be
 retried. Make it empty to never expire jobs. It has to be no less than 1 day,
 for example: <code>15 days</code>, <code>1 month</code>, <code>2 years</code>.
 
-As of June 22, 2020 the [value is set](../../gitlab_com/index.md#gitlab-cicd) to 3 months on GitLab.com. Jobs created before that date were archived after September 22, 2020.
+For the value set for GitLab.com, see [Scheduled job archiving](../../gitlab_com/index.md#gitlab-cicd).
 
 ## Protect CI/CD variables by default
 
@@ -233,7 +230,7 @@ To select a CI/CD template for the required pipeline configuration:
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand the **Required pipeline configuration** section.
 1. Select a CI/CD template from the dropdown.
-1. Click **Save changes**.
+1. Select **Save changes**.
 
 ## Package Registry configuration
 
@@ -272,7 +269,7 @@ To set the maximum file size:
 1. Expand the **Package Registry** section.
 1. Find the package type you would like to adjust.
 1. Enter the maximum file size, in bytes.
-1. Click **Save size limits**.
+1. Select **Save size limits**.
 
 ## Prevent users from registering runners
 
diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md
index fac23cb48af..42e0c9faf9f 100644
--- a/doc/user/admin_area/settings/gitaly_timeouts.md
+++ b/doc/user/admin_area/settings/gitaly_timeouts.md
@@ -22,6 +22,6 @@ The following timeouts are available.
 
 | Timeout | Default    | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 |:--------|:-----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the [worker timeout](../../../administration/operations/puma.md#worker-timeout) that can be configured for [Puma](../../../install/requirements.md#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. |
+| Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the [worker timeout](../../../administration/operations/puma.md#change-the-worker-timeout) that can be configured for [Puma](../../../install/requirements.md#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. |
 | Fast    | 10 seconds | Timeout for fast Gitaly operations used within requests, sometimes multiple times. For example, checking if a repository exists on disk. If fast operations exceed this threshold, there may be a problem with a storage shard. Failing fast can help maintain the stability of the GitLab instance.                                                                                                                                                                                                                                                                        |
 | Medium  | 30 seconds | Timeout for Gitaly operations that should be fast (possibly within requests) but preferably not used multiple times within a request. For example, loading blobs. Timeout that should be set between Default and Fast.                                                                                                                                                                                                                                                                                                                                                       |
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index a581fd4aebc..052b6e26c07 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -130,6 +130,7 @@ The **Network** settings contain:
     Git LFS requests that supersede the user and IP rate limits.
   - [Files API Rate Limits](files_api_rate_limits.md) - Configure specific limits for
     Files API requests that supersede the user and IP rate limits.
+  - [Search rate limits](../../../administration/instance_limits.md#search-rate-limit) - Configure global search request rate limits for authenticated and unauthenticated users.
   - [Deprecated API Rate Limits](deprecated_api_rate_limits.md) - Configure specific limits
     for deprecated API requests that supersede the user and IP rate limits.
 - [Outbound requests](../../../security/webhooks.md) - Allow requests to the local network from hooks and services.
@@ -170,6 +171,8 @@ The **Repository** settings contain:
 
 - [Repository's custom initial branch name](../../project/repository/branches/default.md#instance-level-custom-initial-branch-name) -
   Set a custom branch name for new repositories created in your instance.
+- [Repository's initial default branch protection](../../project/repository/branches/default.md#instance-level-default-branch-protection) -
+  Configure the branch protections to apply to every repository's default branch.
 - [Repository mirror](visibility_and_access_controls.md#enable-project-mirroring) -
   Configure repository mirroring.
 - [Repository storage](../../../administration/repository_storage_types.md) - Configure storage path settings.
diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
index 88be73c3215..56e240a8d39 100644
--- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md
+++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
@@ -107,7 +107,7 @@ attached into the response headers.
 | `RateLimit-Limit`     | `60`                            | The request quota for the client **each minute**. If the rate limit period set in the admin area is different from 1 minute, the value of this header is adjusted to approximately the nearest 60-minute period. |
 | `RateLimit-Name`      | `throttle_authenticated_web`    | Name of the throttle blocking the requests.                                                                                                                                                                      |
 | `RateLimit-Observed`  | `67`                            | Number of requests associated to the client in the time window.                                                                                                                                                  |
-| `RateLimit-Remaining` | `0`                             | Remaining quota in the time window. The result of `RateLimit-Limit` - `RateLimit-Remaining`.                                                                                                                     |
+| `RateLimit-Remaining` | `0`                             | Remaining quota in the time window. The result of `RateLimit-Limit` - `RateLimit-Observed`.                                                                                                                     |
 | `RateLimit-Reset`     | `1609844400`                    | [Unix time](https://en.wikipedia.org/wiki/Unix_time)-formatted time when the request quota is reset.                                                                                                             |
 | `RateLimit-ResetTime` | `Tue, 05 Jan 2021 11:00:00 GMT` | [RFC2616](https://tools.ietf.org/html/rfc2616#section-3.3.1)-formatted date and time when the request quota is reset.                                                                                            |
 | `Retry-After`         | `30`                            | Remaining duration **in seconds** until the quota is reset. This is a [standard HTTP header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After).                                             |
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 c38b2455a8d..2165dc54899 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -17,54 +17,6 @@ To access the visibility and access control options:
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
 
-## Protect default branches
-
-With this option, you can define [branch protections](../../project/protected_branches.md)
-to apply to every repository's [default branch](../../project/repository/branches/default.md).
-These protections specify the user roles with permission to push to default branches.
-
-This setting applies only to each repository's default branch. To protect other branches,
-you must configure [branch protection in the repository](../../project/protected_branches.md),
-or configure [branch protection for groups](../../group/index.md#change-the-default-branch-protection-of-a-group).
-
-To change the default branch protection for the entire instance:
-
-1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Visibility and access controls** section.
-1. Select a **Default branch protection**:
-   - **Not protected** - Both developers and maintainers can push new commits
-     and force push.
-   - **Protected against pushes** - Developers cannot push new commits, but are
-     allowed to accept merge requests to the branch. Maintainers can push to the branch.
-   - **Partially protected** - Both developers and maintainers can push new commits,
-     but cannot force push.
-   - **Fully protected** - Developers cannot push new commits, but maintainers can.
-     No one can force push.
-1. To allow group owners to override the instance's default branch protection, select
-   [**Allow owners to manage default branch protection per group**](#prevent-overrides-of-default-branch-protection).
-1. Select **Save changes**.
-
-### Prevent overrides of default branch protection **(PREMIUM SELF)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211944) in GitLab 13.0.
-
-Instance-level protections for [default branch](../../project/repository/branches/default.md)
-can be overridden on a per-group basis by the group's owner. In
-[GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can
-disable this privilege for group owners, enforcing the instance-level protection rule:
-
-1. Sign in to GitLab as a user with Administrator access level.
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Settings > General**.
-1. Expand the **Visibility and access controls** section.
-1. Deselect the **Allow owners to manage default branch protection per group** checkbox.
-1. Select **Save changes**.
-
-NOTE:
-GitLab administrators can still update the default branch protection of a group.
-
 ## Define which roles can create projects
 
 Instance-level protections for project creation define which roles can