Add latest changes from gitlab-org/gitlab@master

9 files changed, 99 insertions, 337 deletions

diff --git a/doc/administration/geo/replication/version_specific_upgrades.md b/doc/administration/geo/replication/version_specific_upgrades.md
index c0215c4551c..7e3160822b9 100644
--- a/doc/administration/geo/replication/version_specific_upgrades.md
+++ b/doc/administration/geo/replication/version_specific_upgrades.md
@@ -104,323 +104,3 @@ If you are running an affected version and need to remove your Primary site, you
 ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
 
 GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.12
-
-### Secondary sites re-download all LFS files upon upgrade
-
-We found an issue where [secondary sites re-download all LFS files](https://gitlab.com/gitlab-org/gitlab/-/issues/334550) upon upgrade. This bug:
-
-- Only applies to Geo secondary sites that have replicated LFS objects.
-- Is _not_ a data loss risk.
-- Causes churn and wasted bandwidth re-downloading all LFS objects.
-- May impact performance for GitLab installations with a large number of LFS files.
-
-If you don't have many LFS objects or can stand a bit of churn, then it is safe to let the secondary sites re-download LFS objects.
-If you do have many LFS objects, or many Geo secondary sites, or limited bandwidth, or a combination of them all, then we recommend you skip GitLab 13.12.0 through 13.12.6 and upgrade to GitLab 13.12.7 or newer.
-
-#### If you have already upgraded to an affected version, and the re-sync is ongoing
-
-You can manually migrate the legacy sync state to the new state column by running the following command in a [Rails console](../../operations/rails_console.md). It should take under a minute:
-
-```ruby
-Geo::LfsObjectRegistry.where(state: 0, success: true).update_all(state: 2)
-```
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.11
-
-We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitlab-org/gitlab/-/issues/330787) on Geo secondaries and on any GitLab instance if maintenance mode is enabled. This was caused by a regression in GitLab Workhorse. This is fixed in the [GitLab 13.11.4 patch release](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/). To avoid this issue, upgrade to GitLab 13.11.4 or later.
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.10
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.9
-
-### Error during zero-downtime upgrade: `cannot drop column asset_proxy_whitelist`
-
-We've detected an issue [with a column rename](https://gitlab.com/gitlab-org/gitlab/-/issues/324160)
-that prevents upgrades to GitLab 13.9.0, 13.9.1, 13.9.2 and 13.9.3 when following the zero-downtime steps. It is necessary
-to perform the following additional steps for the zero-downtime upgrade:
-
-1. Before running the final `sudo gitlab-rake db:migrate` command on the deploy node,
-   execute the following queries using the PostgreSQL console (or `sudo gitlab-psql`)
-   to drop the problematic triggers:
-
-   ```sql
-   drop trigger trigger_e40a6f1858e6 on application_settings;
-   drop trigger trigger_0d588df444c8 on application_settings;
-   drop trigger trigger_1572cbc9a15f on application_settings;
-   drop trigger trigger_22a39c5c25f3 on application_settings;
-   ```
-
-1. Run the final migrations:
-
-   ```shell
-   sudo gitlab-rake db:migrate
-   ```
-
-1. Hot reload `puma` and `sidekiq` services:
-
-   ```shell
-   sudo gitlab-ctl hup puma
-   sudo gitlab-ctl restart sidekiq
-   ```
-
-If you have already run the final `sudo gitlab-rake db:migrate` command on the deploy node and have
-encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you might
-see the following error:
-
-```shell
--- remove_column(:application_settings, :asset_proxy_whitelist)
-rake aborted!
-StandardError: An error has occurred, all later migrations canceled:
-PG::DependentObjectsStillExist: ERROR: cannot drop column asset_proxy_whitelist of table application_settings because other objects depend on it
-DETAIL: trigger trigger_0d588df444c8 on table application_settings depends on column asset_proxy_whitelist of table application_settings
-```
-
-To work around this bug, follow the previous steps to complete the upgrade.
-More details are available [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160).
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.7
-
-- We've detected an issue with the `FetchRemove` call used by Geo secondaries.
-  This causes performance issues as we execute reference transaction hooks for
-  each upgraded reference. Delay any upgrade attempts until this is in the
-  [13.7.5 patch release.](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3002).
-  More details are available [in this issue](https://gitlab.com/gitlab-org/git/-/issues/79).
-- A new secret is generated in `/etc/gitlab/gitlab-secrets.json`.
-  In an HA GitLab or GitLab Geo environment, secrets need to be the same on all nodes.
-  Ensure this new secret is also accounted for if you are manually syncing the file across
-  nodes, or manually specifying secrets in `/etc/gitlab/gitlab.rb`.
-
-## Upgrading to GitLab 13.5
-
-GitLab 13.5 has a [regression that prevents viewing a list of container repositories and registries](https://gitlab.com/gitlab-org/gitlab/-/issues/285475)
-on Geo secondaries. This issue is fixed in GitLab 13.6.1 and later.
-
-## Upgrading to GitLab 13.3
-
-In GitLab 13.3, Geo removed the PostgreSQL [Foreign Data Wrapper](https://www.postgresql.org/docs/11/postgres-fdw.html)
-dependency for the tracking database.
-
-The FDW server, user, and the extension is removed during the upgrade
-process on each secondary site. The GitLab settings related to the FDW in the
-`/etc/gitlab/gitlab.rb`  have been deprecated and can be safely removed.
-
-There are some scenarios like using an external PostgreSQL instance for the
-tracking database where the FDW settings must be removed manually. Enter the
-PostgreSQL console of that instance and remove them:
-
-```shell
-DROP SERVER gitlab_secondary CASCADE;
-DROP EXTENSION IF EXISTS postgres_fdw;
-```
-
-WARNING:
-In GitLab 13.3, promoting a secondary site to a primary while the secondary is
-paused fails. Do not pause replication before promoting a secondary. If the
-site is paused, be sure to resume before promoting. To avoid this issue,
-upgrade to GitLab 13.4 or later.
-
-WARNING:
-Promoting the database during a failover can fail on XFS and filesystems ordering files lexically,
-when using `--force` or `--skip-preflight-checks`, due to [an issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6076) fixed in 13.5.
-The [troubleshooting steps](troubleshooting.md#errors-when-using---skip-preflight-checks-or---force)
-contain a workaround if you run into errors during the failover.
-
-## Upgrading to GitLab 13.2
-
-In GitLab 13.2, promoting a secondary site to a primary while the secondary is
-paused fails. Do not pause replication before promoting a secondary. If the
-site is paused, be sure to resume before promoting. To avoid this issue,
-upgrade to GitLab 13.4 or later.
-
-## Upgrading to GitLab 13.0
-
-Upgrading to GitLab 13.0 requires GitLab 12.10 to already be using PostgreSQL
-version 11. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.10
-
-GitLab 12.10 doesn't attempt to upgrade the embedded PostgreSQL server when
-using Geo, because the PostgreSQL upgrade requires downtime for secondaries
-while reinitializing streaming replication. It must be upgraded manually. For
-the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.9
-
-WARNING:
-GitLab 12.9.0 through GitLab 12.9.3 are affected by
-[a bug that stops repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
-The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
-
-By default, GitLab 12.9 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.8
-
-By default, GitLab 12.8 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.7
-
-WARNING:
-Only upgrade to GitLab 12.7.5 or later. Do not upgrade to versions 12.7.0
-through 12.7.4 because there is [an initialization order bug](https://gitlab.com/gitlab-org/gitlab/-/issues/199672) that causes Geo secondaries to set the incorrect database connection pool size.
-[The fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24021) was
-shipped in 12.7.5.
-
-By default, GitLab 12.7 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.6
-
-By default, GitLab 12.6 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.5
-
-By default, GitLab 12.5 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.4
-
-By default, GitLab 12.4 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.3
-
-WARNING:
-If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
-GitLab 12.4 or later. By default, GitLab 12.3 attempts to upgrade the embedded
-PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
-requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.2
-
-WARNING:
-If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
-GitLab 12.4 or later. By default, GitLab 12.2 attempts to upgrade the embedded
-PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
-requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-GitLab 12.2 includes the following minor PostgreSQL upgrades:
-
-- To version `9.6.14`, if you run PostgreSQL 9.6.
-- To version `10.9`, if you run PostgreSQL 10.
-
-This upgrade occurs even if major PostgreSQL upgrades are disabled.
-
-Before [refreshing Foreign Data Wrapper during a Geo upgrade](../../../update/zero_downtime.md#step-4-run-post-deployment-migrations-and-checks),
-restart the Geo tracking database:
-
-```shell
-sudo gitlab-ctl restart geo-postgresql
-```
-
-The restart avoids a version mismatch when PostgreSQL tries to load the FDW
-extension.
-
-## Upgrading to GitLab 12.1
-
-WARNING:
-If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
-GitLab 12.4 or later. By default, GitLab 12.1 attempts to upgrade the embedded
-PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
-requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.0
-
-WARNING:
-This version is affected by a
-[bug that results in new LFS objects not being replicated to Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
-The issue is fixed in GitLab 12.1. Be sure to upgrade to GitLab 12.1 or later.
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md
index eb5b5c4b9fa..d6f1b39d852 100644
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -417,7 +417,7 @@ reasons are:
 - Artifact files might be left on disk and not deleted by housekeeping. Run the
   [Rake task for _orphaned_ artifact files](../raketasks/cleanup.md#remove-orphan-artifact-files)
   to remove these. This script should always find work to do, as it also removes empty directories (see above).
-- [Artifact housekeeping was changed significantly](#artifacts-housekeeping-disabled-in-gitlab-146-to-152),
+- [Artifact housekeeping was changed significantly](#housekeeping-disabled-in-gitlab-146-to-152),
   and you might need to enable a feature flag to used the updated system.
 - The [keep latest artifacts from most recent success jobs](../ci/jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs)
   feature is enabled.
@@ -426,11 +426,20 @@ In these and other cases, identify the projects most responsible
 for disk space usage, figure out what types of artifacts are using the most
 space, and in some cases, manually delete job artifacts to reclaim disk space.
 
-#### Artifacts housekeeping disabled in GitLab 14.6 to 15.2
+#### Artifacts housekeeping
 
-Artifact housekeeping was significantly changed in GitLab 14.10, and the changes
-were back ported to GitLab 14.6 and later. The updated housekeeping must be
-enabled with feature flags [until GitLab 15.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92931).
+Artifacts housekeeping is the process that identifies which artifacts are expired
+and can be deleted.
+
+##### Housekeeping disabled in GitLab 14.6 to 15.2
+
+Artifact housekeeping was disabled in GitLab 14.6. It was significantly improved
+in GitLab 14.10, and the changes were back ported to patch versions of GitLab 14.6 and later,
+introduced behind [feature flags](feature_flags.md) disabled by default. The flags were
+enabled by default [in GitLab 15.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92931).
+
+If artifacts housekeeping does not seem to be working in GitLab 14.6 to GitLab 15.2,
+you should check if the feature flags are enabled.
 
 To check if the feature flags are enabled:
 
@@ -443,15 +452,15 @@ To check if the feature flags are enabled:
      ```ruby
      Feature.enabled?(:ci_detect_wrongly_expired_artifacts, default_enabled: :yaml)
      Feature.enabled?(:ci_update_unlocked_job_artifacts, default_enabled: :yaml)
-     Feature.enabled?(:ci_destroy_unlocked_job_artifacts, default_enabled: :yaml)
+     Feature.enabled?(:ci_job_artifacts_backlog_work, default_enabled: :yaml)
      ```
 
-   - GitLab 15.00 and later:
+   - GitLab 15.0 and later:
 
      ```ruby
      Feature.enabled?(:ci_detect_wrongly_expired_artifacts)
      Feature.enabled?(:ci_update_unlocked_job_artifacts)
-     Feature.enabled?(:ci_destroy_unlocked_job_artifacts)
+     Feature.enabled?(:ci_job_artifacts_backlog_work)
      ```
 
 1. If any of the feature flags are disabled, enable them:
@@ -465,8 +474,10 @@ To check if the feature flags are enabled:
 These changes include switching artifacts from `unlocked` to `locked` if
 they [should be retained](../ci/jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
 
-Artifacts created before this feature was introduced have a status of `unknown`. After they expire,
-these artifacts are not processed by the new housekeeping jobs.
+##### Artifacts with `unknown` status
+
+Artifacts created before housekeeping was updated have a status of `unknown`. After they expire,
+these artifacts are not processed by the new housekeeping.
 
 You can check the database to confirm if your instance has artifacts with the `unknown` status:
 
@@ -530,6 +541,8 @@ Artifacts with locked status `2` are `unknown`. Check
 [issue #346261](https://gitlab.com/gitlab-org/gitlab/-/issues/346261#note_1028871458)
 for more details.
 
+##### Clean up `unknown` artifacts
+
 The Sidekiq worker that processes all `unknown` artifacts is enabled by default in
 GitLab 15.3 and later. It analyzes the artifacts returned by the above database query and
 determines which should be `locked` or `unlocked`. Artifacts are then deleted
diff --git a/doc/administration/settings/account_and_limit_settings.md b/doc/administration/settings/account_and_limit_settings.md
index ca56a322237..592abe814d9 100644
--- a/doc/administration/settings/account_and_limit_settings.md
+++ b/doc/administration/settings/account_and_limit_settings.md
@@ -107,6 +107,34 @@ details.
 
 For GitLab.com repository size limits, read [accounts and limit settings](../../user/gitlab_com/index.md#account-and-limit-settings).
 
+## Maximum remote file size for imports
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) in GitLab 16.3.
+
+You can modify the maximum remote file size for imports from external object storages (for example, AWS) in GitLab.
+
+To modify the maximum import remote file size:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Account and limit**.
+1. Increase or decrease by changing the value in **Maximum import remote file size (MB)**. Set to `0` to set no file size limit.
+
+## Maximum download file size for imports by direct transfer
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) in GitLab 16.3.
+
+You can modify the maximum download file size for imports by direct transfer in GitLab.
+
+To modify the maximum download file size for imports by direct transfer:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Account and limit**.
+1. Increase or decrease by changing the value in **Direct transfer maximum download file size (MB)**. Set to `0` to set no download file size limit.
+
 ## Personal access token prefix
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20968) in GitLab 13.7.
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 9a99354b77b..ae0538104cf 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -12323,6 +12323,8 @@ Information about a connected Agent.
 | <a id="airesponseerrors"></a>`errors` | [`[String!]`](#string) | Errors return by AI API as response. |
 | <a id="airesponserequestid"></a>`requestId` | [`String`](#string) | ID of the original request. |
 | <a id="airesponseresponsebody"></a>`responseBody` | [`String`](#string) | Response body from AI API. |
+| <a id="airesponserole"></a>`role` | [`AiCachedMessageRole!`](#aicachedmessagerole) | Message role. |
+| <a id="airesponsetimestamp"></a>`timestamp` | [`Time!`](#time) | Message timestamp. |
 
 ### `AlertManagementAlert`
 
@@ -25789,6 +25791,7 @@ Name of the check for the compliance standard.
 | Value | Description |
 | ----- | ----------- |
 | <a id="compliancestandardsadherencechecknameprevent_approval_by_merge_request_author"></a>`PREVENT_APPROVAL_BY_MERGE_REQUEST_AUTHOR` | Prevent approval by merge request author. |
+| <a id="compliancestandardsadherencechecknameprevent_approval_by_merge_request_committers"></a>`PREVENT_APPROVAL_BY_MERGE_REQUEST_COMMITTERS` | Prevent approval by merge request committers. |
 
 ### `ComplianceStandardsAdherenceStandard`
 
diff --git a/doc/api/settings.md b/doc/api/settings.md
index 0ed4a45ed07..a854f3331f7 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -43,6 +43,7 @@ Example response:
   "max_attachment_size" : 10,
   "max_export_size": 50,
   "max_import_size": 50,
+  "max_import_remote_file_size": 10240,
   "user_oauth_applications" : true,
   "updated_at" : "2016-01-04T15:44:55.176Z",
   "session_expire_delay" : 10080,
@@ -110,7 +111,8 @@ Example response:
   "jira_connect_application_key": null,
   "jira_connect_proxy_url": null,
   "silent_mode_enabled": false,
-  "package_registry_allow_anyone_to_pull_option": true
+  "package_registry_allow_anyone_to_pull_option": true,
+  "bulk_import_max_download_file_size": 5120
 }
 ```
 
@@ -180,6 +182,7 @@ Example response:
   "max_attachment_size": 10,
   "max_export_size": 50,
   "max_import_size": 50,
+  "max_import_remote_file_size": 10240,
   "session_expire_delay": 10080,
   "default_ci_config_path" : null,
   "default_project_visibility": "internal",
@@ -251,7 +254,8 @@ Example response:
   "projects_api_rate_limit_unauthenticated": 400,
   "silent_mode_enabled": false,
   "security_policy_global_group_approvers_enabled": true,
-  "package_registry_allow_anyone_to_pull_option": true
+  "package_registry_allow_anyone_to_pull_option": true,
+  "bulk_import_max_download_file_size": 5120
 }
 ```
 
@@ -315,6 +319,7 @@ listed in the descriptions of the relevant settings.
 | `auto_devops_enabled`                    | boolean          | no                                   | Enable Auto DevOps for projects by default. It automatically builds, tests, and deploys applications based on a predefined CI/CD configuration. |
 | `automatic_purchased_storage_allocation` | boolean          | no                                   | Enabling this permits automatic allocation of purchased storage in a namespace. Relevant only to EE distributions. |
 | `bulk_import_enabled`                    | boolean          | no                                   | Enable migrating GitLab groups by direct transfer. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/383268) in GitLab 15.8. Setting also [available](../administration/settings/visibility_and_access_controls.md#enable-migration-of-groups-and-projects-by-direct-transfer) in the Admin Area. |
+| `bulk_import_max_download_file_size`                    | integer          | no                                   | Maximum download file size when importing from source GitLab instances by direct transfer. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) in GitLab 16.3. |
 | `can_create_group` | boolean | no | Indicates whether users can create top-level groups. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367754) in GitLab 15.5. Defaults to `true`. |
 | `check_namespace_plan` **(PREMIUM)**     | boolean          | no                                   | Enabling this makes only licensed EE features available to projects if the project namespace's plan includes the feature or if the project is public. |
 | `ci_max_includes`                        | integer          | no                                   | The maximum number of [includes](../ci/yaml/includes.md) per pipeline. Default is `150`. |
@@ -441,6 +446,7 @@ listed in the descriptions of the relevant settings.
 | `max_attachment_size`                    | integer          | no                                   | Limit attachment size in MB. |
 | `max_export_size`                        | integer          | no                                   | Maximum export size in MB. 0 for unlimited. Default = 0 (unlimited). |
 | `max_import_size`                        | integer          | no                                   | Maximum import size in MB. 0 for unlimited. Default = 0 (unlimited). [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to 0 in GitLab 13.8. |
+| `max_import_size`                        | integer          | no                                   | Maximum remote file size for imports from external object storages. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) in GitLab 16.3. |
 | `max_pages_size`                         | integer          | no                                   | Maximum size of pages repositories in MB. |
 | `max_personal_access_token_lifetime` **(ULTIMATE SELF)** | integer | no                                   | Maximum allowable lifetime for access tokens in days. When left blank, default value of 365 is applied. When set, value must be 365 or less. When changed, existing access tokens with an expiration date beyond the maximum allowable lifetime are revoked.|
 | `max_ssh_key_lifetime` **(ULTIMATE SELF)** | integer        | no                                   | Maximum allowable lifetime for SSH keys in days. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1007) in GitLab 14.6. |
diff --git a/doc/ci/runners/saas/gpu_saas_runner.md b/doc/ci/runners/saas/gpu_saas_runner.md
index a05b162ac84..6dc9d8c9534 100644
--- a/doc/ci/runners/saas/gpu_saas_runner.md
+++ b/doc/ci/runners/saas/gpu_saas_runner.md
@@ -44,3 +44,10 @@ gpu-job:
 ```
 
 If you don't want to install larger libraries such as Tensorflow or XGBoost each time you run a job, you can create your own image with all the required components pre-installed.
+Watch this demo to learn how to leverage GPU-enabled SaaS runners to train an XGBoost model:
+<div class="video-fallback">
+  Video demonstration of GitLab GPU-Enabled SaaS runners: <a href="https://youtu.be/tElegG4NCZ0">Train XGboost models with GitLab</a>.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube-nocookie.com/embed/tElegG4NCZ0" frameborder="0" allowfullscreen> </iframe>
+</figure>
diff --git a/doc/development/fe_guide/tooling.md b/doc/development/fe_guide/tooling.md
index 762ef852d74..c1084ab4453 100644
--- a/doc/development/fe_guide/tooling.md
+++ b/doc/development/fe_guide/tooling.md
@@ -155,6 +155,19 @@ $ grep "eslint-disable.*import/no-deprecated" -r .
 ./app/assets/javascripts/issuable_form.js:  // eslint-disable-next-line import/no-deprecated
 ```
 
+### `vue/multi-word-component-names` is disabled in my file
+
+Single name components are discouraged by the
+[Vue style guide](https://vuejs.org/style-guide/rules-essential.html#use-multi-word-component-names).
+
+They are problematic because they can be confused with other HTML components: We could name a
+component `<table>` and it would stop rendering an HTML `<table>`.
+
+To solve this, you should rename the `.vue` file and its references to use at least two words,
+for example:
+
+- `user/table.vue` could be renamed to `user/users_table.vue` and be imported as `UsersTable` and used with `<users-table />`.
+
 ### GraphQL schema and operations validation
 
 We use [`@graphql-eslint/eslint-plugin`](https://www.npmjs.com/package/@graphql-eslint/eslint-plugin)
diff --git a/doc/subscriptions/customers_portal.md b/doc/subscriptions/customers_portal.md
index 96d28a2755d..34069545853 100644
--- a/doc/subscriptions/customers_portal.md
+++ b/doc/subscriptions/customers_portal.md
@@ -36,6 +36,16 @@ To sign in to Customers Portal with your email and to receive a one-time sign-in
 NOTE:
 The one-time sign-in link expires in 24 hours and can only be used once.
 
+## Confirm Customers Portal email address
+
+The first time you sign in to the Customers Portal with a one-time sign-in link,
+you must confirm your email address to maintain access to the Customers Portal. If you sign in
+to the Customers Portal through GitLab.com, you don't need to confirm your email address.
+
+You must also confirm any updates to the account email address. You will receive
+an automatic email with instructions about how to confirm, which you can [resend](https://customers.gitlab.com/customers/confirmation/new)
+if required.
+
 ## Change account owner information
 
 The account owner's personal details are used on invoices. The account owner's email address is used for the [Customers Portal legacy sign-in](#sign-in-to-customers-portal) and license-related email.
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 27e6c3a3a40..f6008b9b31a 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -205,11 +205,13 @@ varies by format:
 GitLab.com has the following account limits enabled. If a setting is not listed,
 the default value [is the same as for self-managed instances](../../administration/settings/account_and_limit_settings.md):
 
-| Setting                       | GitLab.com default |
-|-------------------------------|--------------------|
-| [Repository size including LFS](../../administration/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB |
-| [Maximum import size](../project/settings/import_export.md#import-a-project-and-its-data)                   | 5 GB  |
-| Maximum attachment size       | 100 MB              |
+| Setting                                                                                                            | GitLab.com default |
+|--------------------------------------------------------------------------------------------------------------------|--------------------|
+| [Repository size including LFS](../../administration/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB              |
+| [Maximum import size](../project/settings/import_export.md#import-a-project-and-its-data)                          | 5 GB               |
+| Maximum remote file size for imports from external object storages                                                 | 10 GB              |
+| Maximum download file size when importing from source GitLab instances by direct transfer                          | 5 GB               |
+| Maximum attachment size                                                                                            | 100 MB             |
 
 If you are near or over the repository size limit, you can either
 [reduce your repository size with Git](../project/repository/reducing_the_repo_size_using_git.md)