Add latest changes from gitlab-org/gitlab@master

10 files changed, 75 insertions, 24 deletions

diff --git a/doc/.vale/gitlab/SubstitutionWarning.yml b/doc/.vale/gitlab/SubstitutionWarning.yml
index 7ee32e41ade..706b66f1934 100644
--- a/doc/.vale/gitlab/SubstitutionWarning.yml
+++ b/doc/.vale/gitlab/SubstitutionWarning.yml
@@ -18,7 +18,6 @@ swap:
   file name: filename
   filesystem: file system
   info: information
-  need to: must
   repo: repository
   timezone: time zone
   utilize: use
diff --git a/doc/.vale/gitlab/Wordy.yml b/doc/.vale/gitlab/Wordy.yml
index 7818ecbb74a..716fdc6c38d 100644
--- a/doc/.vale/gitlab/Wordy.yml
+++ b/doc/.vale/gitlab/Wordy.yml
@@ -5,9 +5,12 @@
 #
 # For a list of all options, see https://docs.errata.ai/vale/styles
 extends: substitution
-message: 'Be concise: "%s" is less wordy than "%s".'
+message: '%s "%s".'
 link: https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html
 level: suggestion
 ignorecase: true
 swap:
-  in order to: to
+  in order to: "Be concise: use 'to' rather than"
+  needs? to: "Rewrite the sentence, or use 'must', instead of"
+  note that: "Be concise: rewrite the sentence to not use"
+  please: "Remove this word from the sentence: "
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index a8bebef8f44..9c917be123e 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -192,7 +192,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    for more details.
 
    NOTE:
-   If you need to use `0.0.0.0` or `*` as the listen_address, you also need to add
+   If you need to use `0.0.0.0` or `*` as the listen_address, you also must add
    `127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
    `127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
 
@@ -378,7 +378,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. Configure PostgreSQL:
 
    This step is similar to how we configured the **primary** instance.
-   We need to enable this, even if using a single node.
+   We must enable this, even if using a single node.
 
    Edit `/etc/gitlab/gitlab.rb` and add the following, replacing the IP
    addresses with addresses appropriate to your network configuration:
@@ -407,7 +407,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    ```
 
    For external PostgreSQL instances, see [additional instructions](external_database.md).
-   If you bring a former **primary** node back online to serve as a **secondary** node, then you also need to remove `roles(['geo_primary_role'])` or `geo_primary_role['enable'] = true`.
+   If you bring a former **primary** node back online to serve as a **secondary** node, then you also must remove `roles(['geo_primary_role'])` or `geo_primary_role['enable'] = true`.
 
 1. Reconfigure GitLab for the changes to take effect:
 
@@ -472,7 +472,7 @@ data before running `pg_basebackup`.
      initial replication to take under an hour.
    - Pass `--sslmode=disable` to skip PostgreSQL TLS authentication altogether
      (for example, you know the network path is secure, or you are using a site-to-site
-     VPN). This is **not** safe over the public Internet!
+     VPN). It is **not** safe over the public Internet!
    - You can read more details about each `sslmode` in the
      [PostgreSQL documentation](https://www.postgresql.org/docs/12/libpq-ssl.html#LIBPQ-SSL-PROTECTION);
      the instructions above are carefully written to ensure protection against
@@ -480,7 +480,7 @@ data before running `pg_basebackup`.
    - Change the `--slot-name` to the name of the replication slot
      to be used on the **primary** database. The script attempts to create the
      replication slot automatically if it does not exist.
-   - If you're repurposing an old server into a Geo **secondary** node, you need to
+   - If you're repurposing an old server into a Geo **secondary** node, you must
      add `--force` to the command line.
    - When not in a production machine you can disable backup step if you
      really sure this is what you want by adding `--skip-backup`
@@ -547,7 +547,7 @@ FATAL:  could not connect to the primary server: FATAL:  password authentication
 
 On all GitLab Geo **secondary** servers:
 
-1. The first step isn't necessary from a configuration perspective, since the hashed `'sql_replication_password'`
+1. The first step isn't necessary from a configuration perspective, because the hashed `'sql_replication_password'`
    is not used on the GitLab Geo **secondary**. However in the event that **secondary** needs to be promoted
    to the GitLab Geo **primary**, make sure to match the `'sql_replication_password'` in the secondary
    server configuration.
@@ -612,7 +612,7 @@ and other database best practices.
 
 ##### Step 1. Configure Patroni permanent replication slot on the primary site
 
-To set up database replication with Patroni on a secondary node, we need to
+To set up database replication with Patroni on a secondary node, we must
 configure a _permanent replication slot_ on the primary node's Patroni cluster,
 and ensure password authentication is used.
 
@@ -678,7 +678,7 @@ Leader instance**:
 ##### Step 2. Configure the internal load balancer on the primary site
 
 To avoid reconfiguring the Standby Leader on the secondary site whenever a new
-Leader is elected on the primary site, we need to set up a TCP internal load
+Leader is elected on the primary site, we must set up a TCP internal load
 balancer which gives a single endpoint for connecting to the Patroni
 cluster's Leader.
 
@@ -860,7 +860,7 @@ For each Patroni instance on the secondary site:
 
 ### Migrating from repmgr to Patroni
 
-1. Before migrating, it is recommended that there is no replication lag between the primary and secondary sites and that replication is paused. In GitLab 13.2 and later, you can pause and resume replication with `gitlab-ctl geo-replication-pause` and `gitlab-ctl geo-replication-resume` on a Geo secondary database node.
+1. Before migrating, we recommend that there is no replication lag between the primary and secondary sites and that replication is paused. In GitLab 13.2 and later, you can pause and resume replication with `gitlab-ctl geo-replication-pause` and `gitlab-ctl geo-replication-resume` on a Geo secondary database node.
 1. Follow the [instructions to migrate repmgr to Patroni](../../postgresql/replication_and_failover.md#switching-from-repmgr-to-patroni). When configuring Patroni on each primary site database node, add `patroni['replication_slots'] = { '<slot_name>' => 'physical' }`
 to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your Geo secondary. This ensures that Patroni recognizes the replication slot as permanent and not drop it upon restarting.
 1. If database replication to the secondary was paused before migration, resume replication once Patroni is confirmed working on the primary.
@@ -869,7 +869,7 @@ to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your
 
 Before the introduction of Patroni, Geo had no Omnibus support for HA setups on the secondary node.
 
-With Patroni it's now possible to support that. In order to migrate the existing PostgreSQL to Patroni:
+With Patroni it's now possible to support that. To migrate the existing PostgreSQL to Patroni:
 
 1. Make sure you have a Consul cluster setup on the secondary (similar to how you set it up on the primary).
 1. [Configure a permanent replication slot](#step-1-configure-patroni-permanent-replication-slot-on-the-primary-site).
@@ -894,7 +894,7 @@ A production-ready and secure setup requires at least three Consul nodes, two
 Patroni nodes and one PgBouncer node on the secondary site.
 
 Because of [omnibus-6587](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6587), Consul can't track multiple
-services, so these need to be different than the nodes used for the Standby Cluster database.
+services, so these must be different than the nodes used for the Standby Cluster database.
 
 Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni)
 and other database best practices.
@@ -1037,7 +1037,7 @@ For each node running the `gitlab-rails`, `sidekiq`, and `geo-logcursor` service
    sudo -i
    ```
 
-1. Edit `/etc/gitlab/gitlab.rb` and add the following attributes. You may have other attributes set, but the following need to be set.
+1. Edit `/etc/gitlab/gitlab.rb` and add the following attributes. You may have other attributes set, but the following must be set.
 
    ```ruby
    # Tracking database settings
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index dca99879cc3..8877b1266e0 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -182,7 +182,7 @@ file for the environment, since it isn't generated dynamically.
 ## Troubleshooting
 
 If your SSH traffic is [slow](https://github.com/linux-pam/linux-pam/issues/270)
-or causing high CPU load, be sure to check the size of `/var/log/btmp`, and ensure it is rotated on a regular basis.
+or causing high CPU load, be sure to check the size of `/var/log/btmp`, and ensure it is rotated on a regular basis or after reaching a certain size.
 If this file is very large, GitLab SSH fast lookup can cause the bottleneck to be hit more frequently, thus decreasing performance even further.
 If you are able to, you may consider disabling [`UsePAM` in your `sshd_config`](https://linux.die.net/man/5/sshd_config) to avoid reading `/var/log/btmp` altogether.
 
diff --git a/doc/architecture/blueprints/ci_scale/index.md b/doc/architecture/blueprints/ci_scale/index.md
index 092f8a7119a..be21f824392 100644
--- a/doc/architecture/blueprints/ci_scale/index.md
+++ b/doc/architecture/blueprints/ci_scale/index.md
@@ -174,15 +174,15 @@ Work required to achieve our next CI/CD scaling target is tracked in the
 
 1. ✓ Migrate primary keys to big integers on GitLab.com.
 1. ✓ Implement the new architecture of builds queuing on GitLab.com.
-1. Make the new builds queuing architecture generally available.
-1. Partition CI/CD data using time-decay pattern.
+1. [Make the new builds queuing architecture generally available](https://gitlab.com/groups/gitlab-org/-/epics/6954).
+1. [Partition CI/CD data using time-decay pattern](../ci_data_decay/).
 
 ## Status
 
 |-------------|--------------|
 | Created at  | 21.01.2021   |
 | Approved at | 26.04.2021   |
-| Updated at  | 06.12.2021   |
+| Updated at  | 28.02.2022   |
 
 Status: In progress.
 
diff --git a/doc/user/project/integrations/img/failed_badges.png b/doc/user/project/integrations/img/failed_badges.png
new file mode 100644
index 00000000000..d44415a8687
--- /dev/null
+++ b/doc/user/project/integrations/img/failed_badges.png
diff --git a/doc/user/project/integrations/img/failed_banner.png b/doc/user/project/integrations/img/failed_banner.png
new file mode 100644
index 00000000000..ba40c1301d6
--- /dev/null
+++ b/doc/user/project/integrations/img/failed_banner.png
diff --git a/doc/user/project/integrations/img/failed_banner_error.png b/doc/user/project/integrations/img/failed_banner_error.png
new file mode 100644
index 00000000000..8f4dabbf8c2
--- /dev/null
+++ b/doc/user/project/integrations/img/failed_banner_error.png
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index ace5783c852..e045b77efff 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -62,7 +62,8 @@ You can configure a webhook for a group or a project.
 
 ## Test a webhook
 
-You can trigger a webhook manually, to ensure it's working properly.
+You can trigger a webhook manually, to ensure it's working properly. You can also send
+a test request to re-enable a [disabled webhook](#re-enable-disabled-webhooks).
 
 For example, to test `push events`, your project should have at least one commit. The webhook uses this commit in the webhook.
 
@@ -72,6 +73,8 @@ To test a webhook:
 1. Scroll down to the list of configured webhooks.
 1. From the **Test** dropdown list, select the type of event to test.
 
+You can also test a webhook from its edit page.
+
 ![Webhook testing](img/webhook_testing.png)
 
 ## Create an example webhook receiver
@@ -143,7 +146,32 @@ GitLab webhooks, keep in mind the following:
   GitLab assumes the hook failed and retries it.
   Most HTTP libraries take care of the response for you automatically but if
   you are writing a low-level hook, this is important to remember.
-- GitLab ignores the HTTP status code returned by your endpoint.
+- GitLab usually ignores the HTTP status code returned by your endpoint,
+  unless the `web_hooks_disable_failed` feature flag is set.
+
+### Failing webhooks
+
+> - Introduced in GitLab 13.12 [with a flag](../../../administration/feature_flags.md) named `web_hooks_disable_failed`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/329849) in GitLab 14.9.
+
+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 `web_hooks_disable_failed`.
+The feature is not ready for production use.
+
+If a webhook fails repeatedly, it may be disabled automatically.
+
+Webhooks that return response codes in the `5xx` range are understood to be failing
+intermittently, and are temporarily disabled. This lasts initially
+for 10 minutes. If the hook continues to fail, the back-off period is
+extended on each retry, up to a maximum disabled period of 24 hours.
+
+Webhooks that return failure codes in the `4xx` range are understood to be
+misconfigured, and these are disabled until you manually re-enable
+them. These webhooks are not automatically retried.
+
+See [troubleshooting](#troubleshoot-webhooks) for information on
+how to see if a webhook is disabled, and how to re-enable it.
 
 ## How image URLs are displayed in the webhook body
 
@@ -186,6 +214,13 @@ To view the table:
 
 1. In your project, on the left sidebar, select **Settings > Webhooks**.
 1. Scroll down to the webhooks.
+1. Each [failing webhook](#failing-webhooks) has a badge listing it as:
+
+   - **Failed to connect** if it is misconfigured, and needs manual intervention to re-enable it.
+   - **Fails to connect** if it is temporarily disabled and will retry later.
+  
+   ![Badges on failing webhooks](img/failed_badges.png)
+   
 1. Select **Edit** for the webhook you want to view.
 
 The table includes the following details about each request:
@@ -233,3 +268,17 @@ determined by [CAcert.org](http://www.cacert.org/).
 
 If that is not the case, consider using [SSL Checker](https://www.sslshopper.com/ssl-checker.html) to identify faults.
 Missing intermediate certificates are common causes of verification failure.
+
+### Re-enable disabled webhooks
+
+If a webhook is failing, a banner displays at the top of the edit page explaining
+why it is disabled, and when it will be automatically re-enabled. For example:
+
+![A banner for a failing webhook, warning it failed to connect and will retry in 60 minutes](img/failed_banner.png)
+
+In the case of a failed webhook, an error banner is displayed:
+
+![A banner for a failed webhook, showing an error state, and explaining how to re-enable it](img/failed_banner_error.png)
+
+To re-enable a failing or failed webhook, [send a test request](#test-a-webhook). If the test
+request succeeds, the webhook is re-enabled.
diff --git a/doc/user/search/advanced_search.md b/doc/user/search/advanced_search.md
index 05579696d35..cb272b3feed 100644
--- a/doc/user/search/advanced_search.md
+++ b/doc/user/search/advanced_search.md
@@ -7,7 +7,7 @@ type: reference
 
 # GitLab Advanced Search **(PREMIUM)**
 
-> - Moved to GitLab Premium in 13.9.
+> Moved to GitLab Premium in 13.9.
 
 NOTE:
 This is the user documentation. To configure the Advanced Search,
@@ -147,8 +147,8 @@ its performance:
 
 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 `prevent_abusive_searches`.
-   The feature is not ready for production use.
+ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `prevent_abusive_searches`.
+The feature is not ready for production use.
 
 To prevent abusive searches, such as searches that may result in a Distributed Denial of Service (DDoS), Global Search ignores, logs, and
 doesn't return any results for searches considered abusive according to the following criteria, if `prevent_abusive_searches` feature flag is enabled: