Add latest changes from gitlab-org/gitlab@master

14 files changed, 47 insertions, 339 deletions

diff --git a/doc/administration/index.md b/doc/administration/index.md
index 95db2b7a2e0..0900255fa63 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -121,6 +121,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Creating users](../user/profile/account/create_accounts.md): Create users manually or through authentication integrations.
 - [Libravatar](libravatar.md): Use Libravatar instead of Gravatar for user avatars.
 - [Sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md): block email addresses of specific domains, or allow only specific domains.
+- [Admin mode](../user/admin_area/settings/sign_in_restrictions.md#admin-mode): require that administrators authenticate separately to use administrative access, like `sudo`.
 - [Access restrictions](../user/admin_area/settings/visibility_and_access_controls.md#configure-enabled-git-access-protocols): Define which Git access protocols can be used to talk to GitLab (SSH, HTTP, HTTPS).
 - [Authentication and Authorization](auth/index.md): Configure external authentication with LDAP, SAML, CAS, and additional providers.
   - [Sync LDAP](auth/ldap/index.md)
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md
index d79f322c3f5..8cac8ea1f77 100644
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -636,24 +636,6 @@ If you need to manually remove **all** job artifacts associated with multiple jo
    - `3.months.ago`
    - `1.year.ago`
 
-### Error `Downloading artifacts from coordinator... not found`
-
-When a job attempts to download artifacts from an earlier job, you might receive an error message similar to:
-
-```plaintext
-Downloading artifacts from coordinator... not found  id=12345678 responseStatus=404 Not Found
-```
-
-This can be caused by a `gitlab.rb` file with the following configuration:
-
-```ruby
-gitlab_rails['artifacts_object_store_background_upload'] = false
-gitlab_rails['artifacts_object_store_direct_upload'] = true
-```
-
-To prevent this, comment out or remove those lines, or switch to their [default values](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template), and
-then run `sudo gitlab-ctl reconfigure`.
-
 ### Job artifact upload fails with error 500
 
 If you are using object storage for artifacts and a job artifact fails to upload,
diff --git a/doc/administration/lfs/index.md b/doc/administration/lfs/index.md
index 80ee9278d09..cae2dea5ffe 100644
--- a/doc/administration/lfs/index.md
+++ b/doc/administration/lfs/index.md
@@ -62,8 +62,6 @@ to check which storage services can be integrated with GitLab.
 You can also use external object storage in a private local network. For example,
 [MinIO](https://min.io/) is a standalone object storage service that works with GitLab instances.
 
-GitLab provides two different options for the uploading mechanism: "Direct upload" and "Background upload".
-
 [Read more about using object storage with GitLab](../object_storage.md).
 
 NOTE:
@@ -71,18 +69,10 @@ In GitLab 13.2 and later, we recommend using the
 [consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
 This section describes the earlier configuration format.
 
-**Option 1. Direct upload**
-
 1. User pushes an `lfs` file to the GitLab instance.
 1. GitLab-workhorse uploads the file directly to the external object storage.
 1. GitLab-workhorse notifies GitLab-rails that the upload process is complete.
 
-**Option 2. Background upload**
-
-1. User pushes an `lfs` file to the GitLab instance.
-1. GitLab-rails stores the file in the local file storage.
-1. GitLab-rails then uploads the file to the external object storage asynchronously.
-
 The following general settings are supported.
 
 | Setting             | Description | Default |
@@ -119,9 +109,7 @@ On Omnibus GitLab installations, the settings are prefixed by `lfs_object_store_
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. [Migrate any existing local LFS objects to the object storage](#migrating-to-object-storage).
-   New LFS objects
-   are forwarded to object storage unless
-   `gitlab_rails['lfs_object_store_background_upload']` and `gitlab_rails['lfs_object_store_direct_upload']` is set to `false`.
+   New LFS objects are forwarded to object storage.
 
 ### S3 for installations from source
 
@@ -150,9 +138,7 @@ For source installations the settings are nested under `lfs:` and then
 
 1. Save the file, and then [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 1. [Migrate any existing local LFS objects to the object storage](#migrating-to-object-storage).
-   New LFS objects
-   are forwarded to object storage unless
-   `background_upload` and `direct_upload` is set to `false`.
+   New LFS objects are forwarded to object storage.
 
 ### Migrating to object storage
 
@@ -276,39 +262,6 @@ To delete these references:
    lfs_object.destroy
    ```
 
-### `Google::Apis::TransmissionError: execution expired`
-
-If LFS integration is configured with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
-Sidekiq workers may encounter this error. This is because the uploading timed out with very large files.
-LFS files up to 6 GB can be uploaded without any extra steps, otherwise you need to use the following workaround.
-
-Sign in to Rails console:
-
-```shell
-sudo gitlab-rails console
-```
-
-Set up timeouts:
-
-- These settings are only in effect for the same session. For example, they are not effective for Sidekiq workers.
-- 20 minutes (1200 sec) is enough to upload 30 GB LFS files:
-
-```ruby
-::Google::Apis::ClientOptions.default.open_timeout_sec = 1200
-::Google::Apis::ClientOptions.default.read_timeout_sec = 1200
-::Google::Apis::ClientOptions.default.send_timeout_sec = 1200
-```
-
-Upload LFS files manually (this process does not use Sidekiq at all):
-
-```ruby
-LfsObject.where(file_store: [nil, 1]).find_each do |lfs_object|
-  lfs_object.file.migrate!(ObjectStorage::Store::REMOTE) if lfs_object.file.file.exists?
-end
-```
-
-See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19581)
-
 ### LFS commands fail on TLS v1.3 server
 
 If you configure GitLab to [disable TLS v1.2](https://docs.gitlab.com/omnibus/settings/nginx.html)
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 4cc6a1b86a5..8b7f49d77d9 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -70,7 +70,7 @@ must be enabled, only the following providers can be used:
 - [Azure Blob storage](#azure-blob-storage)
 
 When consolidated object storage is used, direct upload is enabled
-automatically. Background upload is not supported. For storage-specific
+automatically. For storage-specific
 configuration, [direct upload may become the default](https://gitlab.com/gitlab-org/gitlab/-/issues/27331)
 because it does not require a shared folder.
 
diff --git a/doc/api/commits.md b/doc/api/commits.md
index 3fe77dd5f43..d3481eb77c0 100644
--- a/doc/api/commits.md
+++ b/doc/api/commits.md
@@ -695,9 +695,10 @@ Example response:
 ]
 ```
 
-### Post the build status to a commit
+### Set the pipeline status of a commit
 
-Adds or updates a build status of a commit.
+Add or update the pipeline status of a commit. If the commit is associated with a merge request,
+the API call must target the commit in the merge request's source branch.
 
 ```plaintext
 POST /projects/:id/statuses/:sha
diff --git a/doc/architecture/blueprints/pods/images/pods-and-fulfillment.png b/doc/architecture/blueprints/pods/images/pods-and-fulfillment.png
index aab8556a5d3..fea32d1800e 100644
--- a/doc/architecture/blueprints/pods/images/pods-and-fulfillment.png
+++ b/doc/architecture/blueprints/pods/images/pods-and-fulfillment.png
diff --git a/doc/development/import_project.md b/doc/development/import_project.md
index b879d635350..7f5a0faf8fb 100644
--- a/doc/development/import_project.md
+++ b/doc/development/import_project.md
@@ -57,7 +57,7 @@ This method takes longer to import than the other methods and depends on several
 
 This script was introduced in GitLab 12.6 for importing large GitLab project exports.
 
-As part of this script we also disable direct and background upload to avoid situations where a huge archive is being uploaded to GCS (while being inside a transaction, which can cause idle transaction timeouts).
+As part of this script we also disable direct upload to avoid situations where a huge archive is being uploaded to GCS (while being inside a transaction, which can cause idle transaction timeouts).
 
 We can run this script from the terminal:
 
diff --git a/doc/development/uploads/index.md b/doc/development/uploads/index.md
index 41ec71451fb..55c6650ed4a 100644
--- a/doc/development/uploads/index.md
+++ b/doc/development/uploads/index.md
@@ -40,21 +40,9 @@ When using object storage, administrators can control how those files are moved
 This move can happen in one of these ways:
 
 - [Rails controller upload](#rails-controller-upload).
-- [Background upload](#background-upload).
 - [Direct upload](#direct-upload).
 
-These strategies activate as per the following `<feature>.object_store.*` settings:
-
-|                           | `background_upload` = `false` | `background_upload` = `true`    |
-| ------------------------- | ----------------------------- | ------------------------------- |
-| `direct_upload` = `false` | Controller upload             | Background upload               |
-| `direct_upload` = `true`  | Direct upload                 | Direct upload (takes precedence)|
-
 Individual Sidekiq workers might also store files in object storage, which is not something we cover here.
-More importantly, `background_upload` does not imply _all files are uploaded by Sidekiq._
-Sidekiq workers that store files in object storage could still exist when this setting is `false`.
-Those cases are never user-initiated uploads, but they might occur in response to another user-initiated
-action, such as exporting a GitLab repository.
 
 Finally, Workhorse assists most user-initiated uploads using an upload buffering mechanism to keep slow work out of Rails controllers.
 This mechanism is explained in [Workhorse assisted uploads](#workhorse-assisted-uploads),
@@ -98,12 +86,11 @@ GitLab to the object store provider. As mentioned above, there are three differe
 this HTTP request is sent.
 
 - [Rails controller upload](#rails-controller-upload).
-- [Background upload](#background-upload).
 - [Direct upload](#direct-upload).
 
 ### Rails controller upload
 
-When neither background upload nor direct upload are available, Rails uploads the file to object storage
+When direct upload is not available, Rails uploads the file to object storage
 as part of the controller `create` action. Which controller is responsible depends on the kind of file uploaded.
 
 A Rails controller upload is very similar to uploading to local storage. The main difference: Rails must
@@ -115,25 +102,6 @@ keep some of the costly I/O work out of Ruby and Rails. Direct upload does a bet
 
 This strategy is only suitable for small file uploads, as it is subject to Puma's 60 second request timeout.
 
-### Background upload
-
-WARNING:
-This strategy is deprecated in GitLab 14.9 and later, and is scheduled to [be removed in GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/26600).
-
-With background uploads enabled:
-
-1. Files are uploaded as if they were to reside in local storage.
-1. When Rails saves the upload metadata and the transaction completes, a Sidekiq job is scheduled.
-1. The Sidekiq job transfers the file to the object store bucket.
-   - If the job completes, the upload record is updated to reflect the file's new location.
-   - If the job fails or gets lost, the upload stays in local storage and has the lifecycle of a normal local storage upload.
-
-As Rails and Sidekiq must cooperate to move the file to its final destination, it requires shared
-storage and as such is unsuitable for CNG installations. We do not use background upload in GitLab SaaS.
-
-As background upload is an extension of local storage, it benefits from the same [Workhorse assistance](#workhorse-assisted-uploads) to
-keep costly I/O work out of Ruby and Rails.
-
 ### Direct upload
 
 Direct upload is the recommended way to move large files into object storage in CNG installations like GitLab SaaS.
diff --git a/doc/update/with_downtime.md b/doc/update/with_downtime.md
index dfe64a3c2a9..2ad928927a4 100644
--- a/doc/update/with_downtime.md
+++ b/doc/update/with_downtime.md
@@ -6,10 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Multi-node upgrades with downtime **(FREE SELF)**
 
-NOTE:
-This process is a work in progress. You're welcome to provide feedback by either raising a ticket to support,
-or [commenting on this issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6244).
-
 While you can upgrade a multi-node GitLab deployment [with zero downtime](zero_downtime.md),
 there are a number of constraints. In particular, you can upgrade to only one minor release
 at a time, for example, from 14.6 to 14.7, then to 14.8, etc.
@@ -37,9 +33,6 @@ At a high level, the process is:
      substitute the instructions for Omnibus GitLab with your cloud provider's instructions.
 1. Upgrade the GitLab application (Sidekiq, Puma) and start the application up.
 
-If you are a Community Edition user, replace `gitlab-ee` with
-`gitlab-ce` in the following commands.
-
 ## Stop writes to the database
 
 Shut down Puma and Sidekiq on all servers running these processes:
@@ -56,16 +49,7 @@ sudo gitlab-ctl stop puma
 In summary:
 
 1. Check the Consul nodes are all healthy.
-1. Upgrade the GitLab package on all your Consul servers:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
-
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on all your Consul servers.
 1. Restart all GitLab services **one node at a time**:
 
    ```shell
@@ -106,15 +90,7 @@ The Praefect nodes, however, can be upgraded via an AMI redeployment process:
 
 ## Upgrade the Gitaly nodes not part of Gitaly cluster
 
-For Gitaly servers which are not part of Gitaly cluster, update the GitLab package:
-
-```shell
-# Debian/Ubuntu
-sudo apt-get update && sudo apt-get install gitlab-ee
-
-# Centos/RHEL
-sudo yum install gitlab-ee
-```
+For Gitaly servers which are not part of Gitaly cluster, [upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 If you have multiple Gitaly shards or have multiple load-balanced Gitaly nodes
 using NFS, it doesn't matter in which order you upgrade the Gitaly servers.
@@ -123,15 +99,7 @@ using NFS, it doesn't matter in which order you upgrade the Gitaly servers.
 
 For unclustered PostgreSQL servers:
 
-1. Upgrade the GitLab package:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. The upgrade process does not restart PostgreSQL when the binaries are upgraded.
    Restart to load the new version:
@@ -161,15 +129,7 @@ Follow the following process:
    sudo gitlab-ctl patroni members
    ```
 
-1. Upgrade the GitLab package on one of the replica nodes:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on one of the replica nodes.
 
 1. Restart to load the new version:
 
@@ -194,27 +154,11 @@ Follow the following process:
 If you run PgBouncer on your Rails (application) nodes, then
 PgBouncer are upgraded as part of the application server upgrade.
 
-Upgrade the PgBouncer nodes:
-
-```shell
-# Debian/Ubuntu
-sudo apt-get update && sudo apt-get install gitlab-ee
-
-# Centos/RHEL
-sudo yum install gitlab-ee
-```
+[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on the PgBouncer nodes.
 
 ## Upgrade the Redis node
 
-Upgrade a standalone Redis server by updating the GitLab package:
-
-```shell
-# Debian/Ubuntu
-sudo apt-get update && sudo apt-get install gitlab-ee
-
-# Centos/RHEL
-sudo yum install gitlab-ee
-```
+Upgrade a standalone Redis server by [upgrading the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 ## Upgrade Redis HA (using Sentinel) **(PREMIUM SELF)**
 
@@ -269,15 +213,7 @@ running all database migrations. On the deploy node:
       sudo gitlab-ctl reconfigure
       ```
 
-1. Upgrade the GitLab package:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. If you modified `gitlab.rb` on the deploy node to bypass PgBouncer:
    1. Update `gitlab.rb` on the deploy node. Change `gitlab_rails['db_host']`
@@ -300,15 +236,7 @@ set to anything in `gitlab.rb` on these nodes.
 
 They can be upgraded in parallel:
 
-1. Upgrade the GitLab package:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. Ensure all services are restarted:
 
@@ -318,12 +246,4 @@ They can be upgraded in parallel:
 
 ## Upgrade the Monitor node
 
-Upgrade the GitLab package:
-
-```shell
-# Debian/Ubuntu
-sudo apt-get update && sudo apt-get install gitlab-ee
-
-# Centos/RHEL
-sudo yum install gitlab-ee
-```
+[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index eb1d6cef606..e3bf9e7e123 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -132,18 +132,7 @@ load balancer to latest GitLab version.
         sudo touch /etc/gitlab/skip-auto-reconfigure
         ```
 
-    1. Update the GitLab package:
-
-       ```shell
-       # Debian/Ubuntu
-       sudo apt-get update && sudo apt-get install gitlab-ee
-
-       # Centos/RHEL
-       sudo yum install gitlab-ee
-       ```
-
-       If you are a Community Edition user, replace `gitlab-ee` with
-       `gitlab-ce` in the above command.
+    1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
     1. Get the regular migrations and latest code in place. Before running this step,
        the deploy node's `/etc/gitlab/gitlab.rb` configuration file must have
@@ -193,17 +182,7 @@ Before you update the main GitLab application you must (in order):
 
 #### Upgrade Gitaly nodes
 
-Upgrade the Gitaly nodes one at a time to ensure access to Git repositories is maintained:
-
-```shell
-# Debian/Ubuntu
-sudo apt-get update && sudo apt-get install gitlab-ee
-
-# Centos/RHEL
-sudo yum install gitlab-ee
-```
-
-If you are a Community Edition user, replace `gitlab-ee` with `gitlab-ce` in the above command.
+[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on the Gitaly nodes one at a time to ensure access to Git repositories is maintained.
 
 #### Upgrade Praefect
 
@@ -226,17 +205,7 @@ node first and run database migrations.
 
 1. On the **Praefect deploy node**:
 
-   1. Upgrade the GitLab package:
-
-      ```shell
-      # Debian/Ubuntu
-      sudo apt-get update && sudo apt-get install gitlab-ee
-
-      # Centos/RHEL
-      sudo yum install gitlab-ee
-      ```
-
-      If you are a Community Edition user, replace `gitlab-ee` with `gitlab-ce` in the command above.
+   1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
    1. To apply the Praefect database migrations and restart Praefect, run:
 
@@ -246,13 +215,7 @@ node first and run database migrations.
 
 1. On all **remaining Praefect nodes**:
 
-   1. Upgrade the GitLab package:
-
-      ```shell
-      sudo apt-get update && sudo apt-get install gitlab-ee
-      ```
-
-      If you are a Community Edition user, replace `gitlab-ee` with `gitlab-ce` in the command above.
+   1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
    1. Ensure nodes are running the latest code:
 
@@ -279,17 +242,7 @@ node throughout the process.
 
 **PostgreSQL only nodes**
 
-- Update the GitLab package
-
-  ```shell
-  # Debian/Ubuntu
-  sudo apt-get update && sudo apt-get install gitlab-ee
-
-  # Centos/RHEL
-  sudo yum install gitlab-ee
-  ```
-
-  If you are a Community Edition user, replace `gitlab-ee` with `gitlab-ce` in the above command.
+- [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 - Ensure nodes are running the latest code
 
@@ -299,17 +252,7 @@ node throughout the process.
 
 **Deploy node**
 
-- Update the GitLab package
-
-  ```shell
-  # Debian/Ubuntu
-  sudo apt-get update && sudo apt-get install gitlab-ee
-
-  # Centos/RHEL
-  sudo yum install gitlab-ee
-  ```
-
-  If you are a Community Edition user, replace `gitlab-ee` with `gitlab-ce` in the above command.
+- [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 - If you're using PgBouncer:
 
@@ -341,13 +284,7 @@ node throughout the process.
 
 **All nodes _excluding_ the Deploy node**
 
-- Update the GitLab package
-
-  ```shell
-  sudo apt-get update && sudo apt-get install gitlab-ee
-  ```
-
-  If you are a Community Edition user, replace `gitlab-ee` with `gitlab-ce` in the above command.
+- [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 - Ensure nodes are running the latest code
 
@@ -514,15 +451,7 @@ Log in to your **primary** node, executing the following:
    sudo gitlab-ctl reconfigure
    ```
 
-1. Update the GitLab package:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. To get the database migrations and latest code in place, run:
 
@@ -552,15 +481,7 @@ On each **secondary** node, executing the following:
    sudo gitlab-ctl reconfigure
    ```
 
-1. Update the GitLab package:
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. To get the database migrations and latest code in place, run:
 
@@ -669,15 +590,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 **On primary Gitaly only nodes**
 
-1. Update the GitLab package
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. Ensure nodes are running the latest code
 
@@ -687,15 +600,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 **On the primary "deploy node"**
 
-1. Update the GitLab package
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. If you're using PgBouncer:
 
@@ -737,15 +642,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 **On all primary nodes _excluding_ the primary "deploy node"**
 
-1. Update the GitLab package
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. Ensure nodes are running the latest code
 
@@ -784,15 +681,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 **On secondary Gitaly only nodes**
 
-1. Update the GitLab package
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. Ensure nodes are running the latest code
 
@@ -802,15 +691,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 **On the secondary "deploy node"**
 
-1. Update the GitLab package
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. To get the regular database migrations and latest code in place, run
 
@@ -837,15 +718,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 **On all secondary nodes _excluding_ the secondary "deploy node"**
 
-1. Update the GitLab package
-
-   ```shell
-   # Debian/Ubuntu
-   sudo apt-get update && sudo apt-get install gitlab-ee
-
-   # Centos/RHEL
-   sudo yum install gitlab-ee
-   ```
+1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 1. Ensure nodes are running the latest code
 
diff --git a/doc/user/admin_area/settings/sign_in_restrictions.md b/doc/user/admin_area/settings/sign_in_restrictions.md
index 4ea420d7ca6..36188da356e 100644
--- a/doc/user/admin_area/settings/sign_in_restrictions.md
+++ b/doc/user/admin_area/settings/sign_in_restrictions.md
@@ -84,7 +84,7 @@ To enable Admin Mode through the UI:
 
 To turn on Admin Mode for your current session and access potentially dangerous resources:
 
-1. On the top bar, select **Enable Admin Mode**.
+1. On the top bar, select **Main menu > Enter Admin Mode**.
 1. Try to access any part of the UI with `/admin` in the URL (which requires administrator access).
 
 When Admin Mode status is disabled or turned off, administrators cannot access resources unless
@@ -95,7 +95,11 @@ if they try to open a private group or project, unless they are members of that
 authentication are supported by Admin Mode. Admin Mode status is stored in the current user session and remains active until either:
 
 - It is explicitly disabled.
-- It is disabled automatically after a timeout.
+- It is disabled automatically after six hours.
+
+### Turn off Admin Mode for your session
+
+To turn off Admin Mode for your current session, on the top bar, select **Main menu > Leave Admin mode**.
 
 ### Limitations of Admin Mode
 
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index 76415596dce..a7de85b86df 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -190,6 +190,12 @@ To disable it:
 Feature.disable(:soft_email_confirmation)
 ```
 
+## Set up LDAP user filter
+
+You can limit GitLab access to a subset of the LDAP users on your LDAP server.
+
+See the [documentation on setting up an LDAP user filter](../../../administration/auth/ldap/index.md#set-up-ldap-user-filter) for more information.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index fceec006a1a..db90bafaaa5 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -63,7 +63,7 @@ Bamboo. For example, `https://bamboo.example.com/browse/PROJ-PLAN`.
 
 ## Update Bamboo build status in GitLab
 
-You can use a script that uses the [commit status API](../../../api/commits.md#post-the-build-status-to-a-commit)
+You can use a script that uses the [commit status API](../../../api/commits.md#set-the-pipeline-status-of-a-commit)
 and Bamboo build variables to:
 
 - Update the commit with the build status.
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index 7b7619cfeb5..8d7fbf6e24e 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -78,7 +78,7 @@ threads. Some quick actions might not be available to all subscription tiers.
 | `/health_status <value>`                                                                         | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Set [health status](issues/managing_issues.md#health-status). Valid options for `<value>` are `on_track`, `needs_attention`, and `at_risk` ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213814) in GitLab 14.7).                                                                                                                                                                                                                           |
 | `/invite_email email1 email2`                                                                    | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Add up to six email participants. This action is behind feature flag `issue_email_participants` and is not yet supported in issue templates.                                                                                                                                                                                                                                                                                                              |
 | `/iteration *iteration:"iteration name"`                                                         | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Set iteration. For example, to set the `Late in July` iteration: `/iteration *iteration:"Late in July"` ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/196795) in GitLab 13.1).                                                                                                                                                                                                                                                              |
-| `/label ~label1 ~label2`                                                                         | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Add one or more labels. Label names can also start without a tilde (`~`), but mixed syntax is not supported.                                                                                                                                                                                                                                                                                                                                              |
+| `/label ~label1 ~label2` or `/labels ~label1 ~label2`                                            | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Add one or more labels. Label names can also start without a tilde (`~`), but mixed syntax is not supported.                                                                                                                                                                                                                                                                                                                                              |
 | `/lock`                                                                                          | **{check-circle}** Yes | **{check-circle}** Yes | **{dotted-circle}** No | Lock the discussions.                                                                                                                                                                                                                                                                                                                                                                                                                                     |
 | `/link`                                                                                          | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Add a link and description to [linked resources](../../operations/incident_management/linked_resources.md) in an incident ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/374964) in GitLab 15.5). |
 | `/merge`                                                                                         | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Merge changes. Depending on the project setting, this may be [when the pipeline succeeds](merge_requests/merge_when_pipeline_succeeds.md), or adding to a [Merge Train](../../ci/pipelines/merge_trains.md).                                                                                                                                                                                                                                              |