Add latest changes from gitlab-org/gitlab@master

24 files changed, 149 insertions, 335 deletions

diff --git a/doc/administration/auth/jwt.md b/doc/administration/auth/jwt.md
index f4e7ea09615..4e000576652 100644
--- a/doc/administration/auth/jwt.md
+++ b/doc/administration/auth/jwt.md
@@ -4,7 +4,7 @@ group: Authentication
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Use JWT as an OAuth 2.0 authentication provider **(FREE SELF)**
+# Use JWT as an authentication provider **(FREE SELF)**
 
 To enable the JWT OmniAuth provider, you must register your application with JWT.
 JWT provides you with a secret key for you to use.
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index d20c9ee4412..80c3a21d953 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -4,7 +4,7 @@ group: Authentication
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Use OpenID Connect as an OAuth 2.0 authentication provider **(FREE SELF)**
+# Use OpenID Connect as an authentication provider **(FREE SELF)**
 
 You can use GitLab as a client application with [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)
 as an OmniAuth provider.
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index d89413b2cf4..829455283b0 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -13,7 +13,7 @@ Configure Gitaly in one of two ways:
 :::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb` and add or change the
-   [Gitaly settings](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/1dd07197c7e5ae23626aad5a4a070a800b670380/files/gitlab-config-template/gitlab.rb.template#L1622-1676).
+   [Gitaly settings](https://gitlab.com/gitlab-org/gitaly/-/blob/master/config.toml.example).
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 :::TabTitle Self-compiled (source)
@@ -1089,6 +1089,33 @@ Example:
 }
 ```
 
+## `cat-file` cache
+
+A lot of Gitaly RPCs need to look up Git objects from repositories.
+Most of the time we use `git cat-file --batch` processes for that. For
+better performance, Gitaly can re-use these `git cat-file` processes
+across RPC calls. Previously used processes are kept around in a
+["Git cat-file cache"](https://about.gitlab.com/blog/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
+To control how much system resources this uses, we have a maximum number of
+cat-file processes that can go into the cache.
+
+The default limit is 100 `cat-file`s, which constitute a pair of
+`git cat-file --batch` and `git cat-file --batch-check` processes. If
+you see errors about "too many open files", or an
+inability to create new processes, you may want to lower this limit.
+
+Ideally, the number should be large enough to handle standard
+traffic. If you raise the limit, you should measure the cache hit ratio
+before and after. If the hit ratio does not improve, the higher limit is
+probably not making a meaningful difference. Here is an example
+Prometheus query to see the hit rate:
+
+```plaintext
+sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_cache_total{type=~"(hit)|(miss)"}[5m]))
+```
+
+Configure the `cat-file` cache in the [Gitaly configuration file](reference.md).
+
 ## Repository consistency checks
 
 Gitaly runs repository consistency checks:
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index 946be6c8af3..169b6e00813 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -4,256 +4,24 @@ group: Gitaly
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Gitaly reference **(FREE SELF)**
+# Example configuration files **(FREE SELF)**
 
-Gitaly is configured via a [TOML](https://github.com/toml-lang/toml)
-configuration file. Unlike self-compiled installations, in Linux package installations you
-would not edit this file directly. For Linux package installations, the default file location is `/var/opt/gitlab/gitaly/config.toml`.
+Gitaly and Gitaly Cluster are configured by using configuration files. The default location of the configuration files
+depends on the type of installation you have:
 
-The configuration file is passed as an argument to the `gitaly` executable, which is usually done by either your Linux
-package installation or your [init](https://en.wikipedia.org/wiki/Init) script.
+- For Linux package installations, the default location for Gitaly and Gitaly Cluster configuration is in the
+  `/etc/gitlab/gitlab.rb` Ruby file.
+- For self-compiled, the default location for Gitaly and Gitaly Cluster configuration is in the
+  `/home/git/gitaly/config.toml` and `/home/git/gitaly/config.prafect.toml` TOML files.
 
-An [example configuration file](https://gitlab.com/gitlab-org/gitaly/blob/master/config.toml.example)
-can be found in the Gitaly project.
+You can find example TOML configuration files in the `gitaly` project for:
 
-## Format
+- Gitaly: <https://gitlab.com/gitlab-org/gitaly/-/blob/master/config.toml.example>
+- Gitaly Cluster: <https://gitlab.com/gitlab-org/gitaly/-/blob/master/config.praefect.toml.example>
 
-At the top level, `config.toml` defines the items described on the table below.
+If you are configuring a Linux package installation, you must convert the examples into Ruby to use them.
 
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `socket_path` | string | yes (if  `listen_addr` is not set) | A path which Gitaly should open a Unix socket. |
-| `listen_addr` | string | yes (if `socket_path` is not set) | TCP address for Gitaly to listen on. |
-| `tls_listen_addr` | string | no | TCP over TLS address for Gitaly to listen on. |
-| `bin_dir`    | string | yes    | Directory containing Gitaly executables. |
-| `prometheus_listen_addr` | string | no | TCP listen address for Prometheus metrics. If not set, no Prometheus listener is started. |
+For more information on:
 
-For example:
-
-```toml
-socket_path = "/home/git/gitlab/tmp/sockets/private/gitaly.socket"
-listen_addr = "localhost:9999"
-tls_listen_addr = "localhost:8888"
-bin_dir = "/home/git/gitaly"
-prometheus_listen_addr = "localhost:9236"
-```
-
-### Authentication
-
-Gitaly can be configured to reject requests that do not contain a
-specific bearer token in their headers, which is a security measure to
-be used when serving requests over TCP:
-
-```toml
-[auth]
-# A non-empty token enables authentication.
-token = "the secret token"
-```
-
-Authentication is disabled when the token setting in `config.toml` is absent or
-an empty string.
-
-It is possible to temporarily disable authentication with the `transitioning`
-setting. This allows you to monitor if all clients are
-authenticating correctly without causing a service outage for clients
-that are still to be configured correctly:
-
-```toml
-[auth]
-token = "the secret token"
-transitioning = true
-```
-
-WARNING:
-Remember to disable `transitioning` when you are done
-changing your token settings.
-
-All authentication attempts are counted in Prometheus under
-the [`gitaly_authentications_total` metric](monitoring.md#queries).
-
-### TLS
-
-Gitaly supports TLS encryption. You need to bring your own certificates as
-this isn't provided automatically.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `certificate_path` | string | no | Path to the certificate. |
-| `key_path` | string | no | Path to the key. |
-
-```toml
-tls_listen_addr = "localhost:8888"
-
-[tls]
-certificate_path = '/home/git/cert.cert'
-key_path = '/home/git/key.pem'
-```
-
-[Read more](tls_support.md) about TLS in Gitaly.
-
-### Storage
-
-GitLab repositories are grouped into directories known as storages, such as
-`/home/git/repositories`. They contain bare repositories managed
-by GitLab with names, such as `default`.
-
-These names and paths are also defined in the `gitlab.yml` configuration file of
-GitLab. When you run Gitaly on the same machine as GitLab (the default
-and recommended configuration) storage paths defined in the Gitaly `config.toml`
-must match those in `gitlab.yml`.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `storage` | array | yes | An array of storage shards. |
-| `path` | string | yes | The path to the storage shard. |
-| `name` | string | yes | The name of the storage shard. |
-
-For example:
-
-```toml
-[[storage]]
-path = "/path/to/storage/repositories"
-name = "my_shard"
-
-[[storage]]
-path = "/path/to/other/repositories"
-name = "other_storage"
-```
-
-### Git
-
-The following values can be set in the `[git]` section of the configuration file.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `bin_path` | string | no | Path to Git binary. If not set, is resolved using `PATH`. |
-| `catfile_cache_size` | integer | no | Maximum number of cached [cat-file processes](#cat-file-cache). Default is `100`. |
-| `signing_key` | string | no | Path to [GPG signing key](configure_gitaly.md#configure-commit-signing-for-gitlab-ui-commits). If not set, Gitaly doesn't sign commits made using the UI. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/19185) in GitLab 15.4. |
-
-#### `cat-file` cache
-
-A lot of Gitaly RPCs need to look up Git objects from repositories.
-Most of the time we use `git cat-file --batch` processes for that. For
-better performance, Gitaly can re-use these `git cat-file` processes
-across RPC calls. Previously used processes are kept around in a
-["Git cat-file cache"](https://about.gitlab.com/blog/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
-To control how much system resources this uses, we have a maximum number of
-cat-file processes that can go into the cache.
-
-The default limit is 100 `cat-file`s, which constitute a pair of
-`git cat-file --batch` and `git cat-file --batch-check` processes. If
-you are seeing errors complaining about "too many open files", or an
-inability to create new processes, you may want to lower this limit.
-
-Ideally, the number should be large enough to handle standard
-traffic. If you raise the limit, you should measure the cache hit ratio
-before and after. If the hit ratio does not improve, the higher limit is
-probably not making a meaningful difference. Here is an example
-Prometheus query to see the hit rate:
-
-```plaintext
-sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_cache_total{type=~"(hit)|(miss)"}[5m]))
-```
-
-#### Custom Hooks
-
-> Method of configuring custom hooks directory documented here is preferred from GitLab 16.4. `[gitlab-shell] dir` configuration is no longer required.
-
-Gitaly supports [custom Git hooks](../server_hooks.md) that are
-used to perform tasks based on changes performed in any repository. The custom
-hooks directory is configured in the `[hooks]` section:
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `custom_hooks_dir` | string | no | The directory where custom Git hooks are installed. |
-
-Example:
-
-```toml
-[hooks]
-custom_hooks_dir = "/home/git/custom-hooks"
-```
-
-If left unset, no custom hooks are used.
-
-### GitLab
-
-> Method of configuring custom hooks directory documented here is preferred from GitLab 16.4. `[gitlab-shell] dir` configuration is no longer required.
-
-Gitaly must connect to the GitLab application to perform access
-checks when a user performs a change. The parameters to connect to GitLab must
-be configured in the `[gitlab]` section.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `url` | string | yes | The URL of the GitLab server.
-| `secret` | string | no | The secret token used to authenticate with GitLab. |
-| `secret_file` | string | no | The path of the file containing the secret token used to authenticate with GitLab. |
-
-Only one of `secret` or `secret_file` can be configured.
-
-### Prometheus
-
-You can optionally configure Gitaly to record histogram latencies on GRPC method
-calls in Prometheus.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `grpc_latency_buckets` | array | no | Prometheus stores each observation in a bucket, which means you'd get an approximation of latency. Optimizing the buckets gives more control over the accuracy of the approximation. |
-
-Example:
-
-```toml
-prometheus_listen_addr = "localhost:9236"
-
-[prometheus]
-grpc_latency_buckets = [0.001, 0.005, 0.025, 0.1, 0.5, 1.0, 10.0, 30.0, 60.0, 300.0, 1500.0]
-```
-
-### Logging
-
-The following values configure logging in Gitaly under the `[logging]` section.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `format` | string | no | Log format: `text` or `json`. Default: `text`. |
-| `level`  | string | no | Log level: `debug`, `info`, `warn`, `error`, `fatal`, or `panic`. Default: `info`. |
-| `sentry_dsn` | string | no | Sentry DSN (Data Source Name) for exception monitoring. |
-| `sentry_environment` | string | no | [Sentry Environment](https://docs.sentry.io/product/sentry-basics/environments/) for exception monitoring. |
-
-While the main Gitaly application logs go to `stdout`, there are some extra log
-files that go to a configured directory, like the GitLab Shell logs.
-GitLab Shell does not support `panic` or `trace` level logs:
-
-- `panic` falls back to `error`.
-- `trace` falls back to `debug`.
-- Any other invalid log levels default to `info`.
-
-Example:
-
-```toml
-[logging]
-level = "warn"
-dir = "/home/gitaly/logs"
-format = "json"
-sentry_dsn = "https://<key>:<secret>@sentry.io/<project>"
-ruby_sentry_dsn = "https://<key>:<secret>@sentry.io/<project>"
-```
-
-## Concurrency
-
-You can adjust the `concurrency` of each RPC endpoint.
-
-| Name | Type | Required | Description |
-| ---- | ---- | -------- | ----------- |
-| `concurrency` | array | yes | An array of RPC endpoints. |
-| `rpc` | string | no | The name of the RPC endpoint (`/gitaly.RepositoryService/GarbageCollect`). |
-| `max_per_repo` | integer | no | Concurrency per RPC per repository. |
-
-Example:
-
-```toml
-[[concurrency]]
-rpc = "/gitaly.RepositoryService/GarbageCollect"
-max_per_repo = 1
-```
+- Configuring Gitaly, see [Configure Gitaly](configure_gitaly.md).
+- Configuring Gitaly Cluster, see [Configure Gitaly Cluster](praefect.md).
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md
index 33dc2020331..0658af2360b 100644
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -282,7 +282,7 @@ To migrate back to local storage, you must
 
 If [`artifacts:expire_in`](../ci/yaml/index.md#artifactsexpire_in) is used to set
 an expiry for the artifacts, they are marked for deletion right after that date passes.
-Otherwise, they expire per the [default artifacts expiration setting](../administration/settings/continuous_integration.md).
+Otherwise, they expire per the [default artifacts expiration setting](../administration/settings/continuous_integration.md#default-artifacts-expiration).
 
 Artifacts are deleted by the `expire_build_artifacts_worker` cron job which Sidekiq
 runs every 7 minutes (`*/7 * * * *` in [Cron](../topics/cron/index.md) syntax).
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 098538e580d..9dc29fd5fe0 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -1348,12 +1348,14 @@ Do not upload videos to the product repositories. [Link](#link-to-video) or
 
 ### Link to video
 
-To link out to a video, include a YouTube icon so that readers can scan the page
-for videos before reading:
+To link to a video, include a YouTube icon so that readers can scan the page
+for videos before reading. Include the video's publication date after the link, to help identify
+videos that might be out-of-date.
 
 ```markdown
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an overview, see [Video Title](link-to-video).
+<!-- Video published on YYYY-MM-DD -->
 ```
 
 You can link any up-to-date video that's useful to the GitLab user.
@@ -1383,6 +1385,8 @@ To embed a video:
    (`https://www.youtube-nocookie.com/embed/VIDEO-ID`),
    and paste it, replacing the content of the `src` field in the
    `iframe` tag.
+1. Include the video's publication date below the link, to help identify
+   videos that might be out-of-date.
 
 ```html
 leave a blank line here
@@ -1392,6 +1396,7 @@ leave a blank line here
 <figure class="video-container">
   <iframe src="https://www.youtube-nocookie.com/embed/MqL6BMOySIQ" frameborder="0" allowfullscreen> </iframe>
 </figure>
+<!-- Video published on YYYY-MM-DD -->
 leave a blank line here
 ```
 
diff --git a/doc/index.md b/doc/index.md
index 362bbab3607..617ed547f77 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -62,10 +62,10 @@ For more information about GitLab account management, see:
 
 If you are coming to GitLab from another platform, the following information is useful:
 
-| Topic                                               | Description |
-|:----------------------------------------------------|:------------|
-| [Importing to GitLab](user/project/import/index.md) | Import your projects from GitHub, Bitbucket, GitLab.com, FogBugz, and SVN into GitLab. |
-| [Migrating from SVN](user/project/import/index.md#import-from-subversion)    | Convert a SVN repository to Git and GitLab. |
+| Topic                                                                                  | Description |
+|:---------------------------------------------------------------------------------------|:------------|
+| [Importing to GitLab](user/project/import/index.md)                                    | Import your projects from GitHub, Bitbucket, GitLab.com, FogBugz, and SVN into GitLab. |
+| [Migrating from SVN](user/project/import/index.md#import-repositories-from-subversion) | Convert a SVN repository to Git and GitLab. |
 
 ## Build an integration with GitLab
 
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index b5515a730d3..8f2e121cb26 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -4,7 +4,7 @@ group: Authentication
 info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
-# Use Kerberos as an OAuth 2.0 authentication provider **(FREE SELF)**
+# Integrate GitLab with Kerberos **(FREE SELF)**
 
 GitLab can integrate with [Kerberos](https://web.mit.edu/kerberos/) as an authentication mechanism.
 
diff --git a/doc/integration/shibboleth.md b/doc/integration/shibboleth.md
index f30f073bf08..0ff99a144c2 100644
--- a/doc/integration/shibboleth.md
+++ b/doc/integration/shibboleth.md
@@ -4,7 +4,7 @@ group: Authentication
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Use Shibboleth as an OAuth 2.0 authentication provider **(FREE SELF)**
+# Use Shibboleth as an authentication provider **(FREE SELF)**
 
 NOTE:
 Use the [GitLab SAML integration](saml.md) to integrate specific Shibboleth identity providers (IdPs). For Shibboleth federation support (Discovery Service), use this document.
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
index 54ade6c1066..8a76ef02215 100644
--- a/doc/integration/vault.md
+++ b/doc/integration/vault.md
@@ -4,7 +4,7 @@ group: Environments
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Use Vault as a GitLab OpenID Connect authentication provider **(FREE ALL)**
+# Vault authentication with GitLab OpenID Connect **(FREE ALL)**
 
 [Vault](https://www.vaultproject.io/) is a secrets management application offered by HashiCorp.
 It allows you to store and manage sensitive information such as secret environment
diff --git a/doc/operations/img/tracing_details_v16_7.png b/doc/operations/img/tracing_details_v16_7.png
new file mode 100644
index 00000000000..2e9cb180994
--- /dev/null
+++ b/doc/operations/img/tracing_details_v16_7.png
diff --git a/doc/operations/img/tracing_drawer_v16_7.png b/doc/operations/img/tracing_drawer_v16_7.png
new file mode 100644
index 00000000000..263151edaab
--- /dev/null
+++ b/doc/operations/img/tracing_drawer_v16_7.png
diff --git a/doc/operations/img/tracing_list_v16_3.png b/doc/operations/img/tracing_list_v16_3.png
deleted file mode 100644
index 93c336d4bd7..00000000000
--- a/doc/operations/img/tracing_list_v16_3.png
+++ /dev/null
diff --git a/doc/operations/img/tracing_list_v16_7.png b/doc/operations/img/tracing_list_v16_7.png
new file mode 100644
index 00000000000..ad186a33bb1
--- /dev/null
+++ b/doc/operations/img/tracing_list_v16_7.png
diff --git a/doc/operations/tracing.md b/doc/operations/tracing.md
index cb31fdd8025..f71f41211d8 100644
--- a/doc/operations/tracing.md
+++ b/doc/operations/tracing.md
@@ -70,6 +70,14 @@ To view the list of traces:
 1. On the left sidebar, select **Search or go to** and find your project.
 1. Select **Monitor > Traces**.
 
-To see the details of a trace, select it from the list.
+To see the details of a trace, select it from the list. You can also select a trace directly from the scatterplot.
 
-![list of traces](img/tracing_list_v16_3.png)
+![list of traces](img/tracing_list_v16_7.png)
+
+The trace details page and a list of spans are displayed.
+
+![tracing details](img/tracing_details_v16_7.png)
+
+To view the attributes for a single span, select it from the list.
+
+![tracing drawer](img/tracing_drawer_v16_7.png)
diff --git a/doc/subscriptions/gitlab_dedicated/index.md b/doc/subscriptions/gitlab_dedicated/index.md
index 0f2fdb43512..ae4a7c2fe3f 100644
--- a/doc/subscriptions/gitlab_dedicated/index.md
+++ b/doc/subscriptions/gitlab_dedicated/index.md
@@ -109,7 +109,7 @@ To help you migrate your data to GitLab Dedicated, you can choose from the follo
     - Use the UI, including [group import](../../user/group/import/index.md) and [project import](../../user/project/settings/import_export.md).
     - Use APIs, including the [group import API](../../api/group_import_export.md) and [project import API](../../api/project_import_export.md).
     - Note: Import functionality behind a feature flag (such as `bulk_import_project`) is not supported in GitLab Dedicated.
-1. When migrating from third-party services, you can use [the GitLab importers](../../user/project/import/index.md#available-project-importers).
+1. When migrating from third-party services, you can use [the GitLab importers](../../user/project/import/index.md#supported-import-sources).
 1. You can perform a fully-automated migration through the [Congregate Automation Tool](../../user/project/import/index.md#automate-group-and-project-import), which supports migrating from existing GitLab instances as well as third-party services.
 
 ## Features that are not available
diff --git a/doc/update/versions/gitlab_16_changes.md b/doc/update/versions/gitlab_16_changes.md
index 57f613dd073..7f34946c35d 100644
--- a/doc/update/versions/gitlab_16_changes.md
+++ b/doc/update/versions/gitlab_16_changes.md
@@ -208,8 +208,8 @@ Specific information applies to installations using Geo:
 ### Self-compiled installations
 
 - A new method of configuring paths for the GitLab secret and custom hooks is preferred in GitLab 16.4 and later:
-  1. Update your configuration `[gitlab] secret_file` to [configure the path](../../administration/gitaly/reference.md#gitlab) to the GitLab secret token.
-  1. If you have custom hooks, update your configuration `[hooks] custom_hooks_dir` to [configure the path](../../administration/gitaly/reference.md#custom-hooks) to
+  1. Update your configuration `[gitlab] secret_file` to [configure the path](../../administration/gitaly/reference.md) to the GitLab secret token.
+  1. If you have custom hooks, update your configuration `[hooks] custom_hooks_dir` to [configure the path](../../administration/gitaly/reference.md) to
      server-side custom hooks.
   1. Remove the `[gitlab-shell] dir` configuration.
 
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 70ac1f737e6..a7b75534800 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -232,9 +232,8 @@ this limit. Repository limits apply to both public and private projects.
 
 ## Default import sources
 
-> Disabling all importers by default for new GitLab self-managed installations [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118970) in GitLab 16.0.
-
-The import sources that are available by default depend on which GitLab you use:
+The [import sources](../project/import/index.md#supported-import-sources) that are available to you by default depend on
+which GitLab you use:
 
 - GitLab.com: all available import sources are enabled by default.
 - GitLab self-managed: no import sources are enabled by default and must be
@@ -252,8 +251,6 @@ The import sources that are available by default depend on which GitLab you use:
 | [Manifest file](../project/import/manifest.md)                                                      | **{check-circle}** Yes | **{dotted-circle}** No      |
 | [Repository by URL](../project/import/repo_by_url.md)                                               | **{check-circle}** Yes | **{dotted-circle}** No      |
 
-[Other importers](../project/import/index.md#available-project-importers) are available.
-
 ## IP range
 
 GitLab.com uses the IP ranges `34.74.90.64/28` and `34.74.226.0/24` for traffic from its Web/API
diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md
index 681174400a2..efc74b7ee1e 100644
--- a/doc/user/project/import/index.md
+++ b/doc/user/project/import/index.md
@@ -4,34 +4,61 @@ group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Import and migrate projects **(FREE ALL)**
+# Import and migrate groups and projects **(FREE ALL)**
 
-If you want to bring existing projects to GitLab or copy GitLab projects to a different location, you can:
+To bring existing projects to GitLab, or copy GitLab groups and projects to a different location, you can:
 
-- Import projects from external systems using one of the [available importers](#available-project-importers).
-- Migrate GitLab projects:
-  - Between two GitLab self-managed instances.
-  - Between a self-managed instance and GitLab.com in both directions.
-  - In the same GitLab instance.
+- Migrate GitLab groups and projects by using direct transfer.
+- Import from supported import sources.
+- Import from other import sources.
 
-For any type of source and target, you can migrate GitLab projects:
+## Migrate from GitLab to GitLab by using direct transfer
 
-- When [migrating groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended),
-  which allows you to migrate all projects in a group simultaneously. Migrating projects by direct transfer is in
-  [Beta](../../../policy/experiment-beta-support.md#beta). The feature is not ready for production use.
-- Using [file exports](../settings/import_export.md). With this method you can migrate projects one by one. No network
-  connection between instances is required.
+The best way to migrate GitLab groups and projects between GitLab instances, or in the same GitLab instance, is
+[by using direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
 
-If you only need to migrate Git repositories, you can [import each project by URL](repo_by_url.md). However, you can't
-import issues and merge requests this way. To retain metadata like issues and merge requests, either:
+You can also migrate GitLab projects by using a GitLab file export, which is a supported import source.
 
-- [Migrate projects with groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
-  This feature is in [Beta](../../../policy/experiment-beta-support.md#beta). It is not ready for production use.
-- Use [file exports](../settings/import_export.md) to import projects.
+## Supported import sources
 
-Keep in mind the limitations of [migrating using file exports](../settings/import_export.md#items-that-are-exported).
-When migrating from self-managed to GitLab.com, user associations (such as comment author)
-are changed to the user who is importing the projects.
+> All importers default to disabled for GitLab self-managed installations. This change was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118970) in GitLab 16.0.
+
+The import sources that are available to you by default depend on which GitLab you use:
+
+- GitLab.com: all available import sources are [enabled by default](../../gitlab_com/index.md#default-import-sources).
+- GitLab self-managed: no import sources are enabled by default and must be
+  [enabled](../../../administration/settings/import_and_export_settings.md#configure-allowed-import-sources).
+
+GitLab can import projects from these supported import sources.
+
+| Import source                                 | Description |
+|:----------------------------------------------|:------------|
+| [Bitbucket Cloud](bitbucket.md)               | Using [Bitbucket.org as an OmniAuth provider](../../../integration/bitbucket.md), import Bitbucket repositories. |
+| [Bitbucket Server](bitbucket_server.md)       | Import repositories from Bitbucket Server (also known as Stash). |
+| [FogBugz](fogbugz.md)                         | Import FogBuz projects. |
+| [Gitea](gitea.md)                             | Import Gitea projects. |
+| [GitHub](github.md)                           | Import from either GitHub.com or GitHub Enterprise. |
+| [GitLab export](../settings/import_export.md) | Migrate projects one by one by using a GitLab export file. |
+| [Manifest file](manifest.md)                 | Upload a manifest file. |
+| [Repository by URL](repo_by_url.md)           | Provide a Git repository URL to create a new project from. |
+
+## Other import sources
+
+You can also read information on importing from these other import sources:
+
+- [ClearCase](clearcase.md)
+- [Concurrent Versions System (CVS)](cvs.md)
+- [Jira (issues only)](jira.md)
+- [Perforce Helix](perforce.md)
+- [Team Foundation Version Control (TFVC)](tfvc.md)
+
+### Import repositories from Subversion
+
+GitLab can not automatically migrate Subversion repositories to Git. Converting Subversion repositories to Git can be
+difficult, but several tools exist including:
+
+- [`git svn`](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git), for very small and basic repositories.
+- [`reposurgeon`](http://www.catb.org/~esr/reposurgeon/repository-editing.html), for larger and more complex repositories.
 
 ## Security
 
@@ -49,35 +76,6 @@ GitLab self-managed administrators can reduce their attack surface by disabling
 
 In GitLab 16.1 and earlier, you should **not** use direct transfer with [scheduled scan execution policies](../../../user/application_security/policies/scan-execution-policies.md).
 
-## Available project importers
-
-You can import projects from:
-
-- [Bitbucket Cloud](bitbucket.md)
-- [Bitbucket Server (also known as Stash)](bitbucket_server.md)
-- [ClearCase](clearcase.md)
-- [CVS](cvs.md)
-- [FogBugz](fogbugz.md)
-- [GitHub.com or GitHub Enterprise](github.md)
-- [Gitea](gitea.md)
-- [Perforce](perforce.md)
-- [TFVC](tfvc.md)
-- [Repository by URL](repo_by_url.md)
-- [Uploading a manifest file (AOSP)](manifest.md)
-- [Jira (issues only)](jira.md)
-
-You can also import any Git repository through HTTP from the **New Project** page. If the repository
-is too large, the import can timeout.
-
-You can then [connect your external repository to get CI/CD benefits](../../../ci/ci_cd_for_external_repos/index.md).
-
-## Import from Subversion
-
-GitLab can not automatically migrate Subversion repositories to Git. Converting Subversion repositories to Git can be difficult, but several tools exist including:
-
-- [`git svn`](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git), for very small and basic repositories.
-- [`reposurgeon`](http://www.catb.org/~esr/reposurgeon/repository-editing.html), for larger and more complex repositories.
-
 ## Migrate using the API
 
 To migrate all data from self-managed to GitLab.com, you can leverage the [API](../../../api/rest/index.md).
diff --git a/doc/user/project/import/repo_by_url.md b/doc/user/project/import/repo_by_url.md
index 5d67d10582d..3c5a40b8d27 100644
--- a/doc/user/project/import/repo_by_url.md
+++ b/doc/user/project/import/repo_by_url.md
@@ -6,7 +6,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Import project from repository by URL **(FREE ALL)**
 
-You can import your existing repositories by providing the Git URL.
+You can import your existing repositories by providing the Git URL. You can't import GitLab issues and merge requests
+this way. Other methods provide more complete import methods.
+
+If the repository is too large, the import can timeout.
 
 ## Prerequisites
 
diff --git a/doc/user/project/merge_requests/approvals/img/group_access_example_01_v16_8.png b/doc/user/project/merge_requests/approvals/img/group_access_example_01_v16_8.png
new file mode 100644
index 00000000000..dc2940f9492
--- /dev/null
+++ b/doc/user/project/merge_requests/approvals/img/group_access_example_01_v16_8.png
diff --git a/doc/user/project/merge_requests/approvals/img/group_access_example_02_v16_8.png b/doc/user/project/merge_requests/approvals/img/group_access_example_02_v16_8.png
new file mode 100644
index 00000000000..e1305ff845c
--- /dev/null
+++ b/doc/user/project/merge_requests/approvals/img/group_access_example_02_v16_8.png
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index c284df8d9aa..2c5d6b89c0e 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -16,7 +16,10 @@ You can define approval rules:
 
 - [As project defaults](#add-an-approval-rule).
 - [Per merge request](#edit-or-override-merge-request-approval-rules).
-- [At the instance level](../../../../administration/admin_area.md)
+
+You can configure approval rules:
+
+- [At the instance level](../../../../administration/admin_area.md).
 
 If you don't define a [default approval rule](#add-an-approval-rule),
 any user can approve a merge request. Even if you don't define a rule, you can still
@@ -311,8 +314,18 @@ For more information about this validation error, read
 ### Groups need explicit or inherited Developer role on a project
 
 A group created to handle approvals may be created in a different area of the
-project hierarchy than the project requiring review. If this happens, the approvals group
-isn't recognized as a valid Code Owner for the project, nor does it display in the
-project's **Approvals** list. To fix this problem, add the approval group as a shared group
-high enough in the shared hierarchy so the project requiring review inherits this
-group of users.
+project hierarchy than the project requiring review. If this happens, members of the
+group may not be able to approve the merge request as they do not have access to it.
+
+For example:
+
+In the group structure below, project 1 belongs to subgroup 1 and subgroup 4 has users.
+
+![Example scenario - project and group hierarchy](img/group_access_example_01_v16_8.png)
+
+Project 1 has a project level approval rule which assigns subgroup 4 as approvers.
+When a merge request is created approvers from subgroup 4 appear in the eligible approvers list.
+However, as users from subgroup 4 do not have permission to view the merge request, the `404` error is returned.
+To grant membership, the group must be invited as a project member. It is now possible for users from subgroup 4 to approve.
+
+![Project members page showing subgroup 4 as a member](img/group_access_example_02_v16_8.png)
diff --git a/doc/user/project/repository/code_suggestions/index.md b/doc/user/project/repository/code_suggestions/index.md
index ae2fe39d363..785c82d96fc 100644
--- a/doc/user/project/repository/code_suggestions/index.md
+++ b/doc/user/project/repository/code_suggestions/index.md
@@ -19,7 +19,7 @@ Write code more efficiently by using generative AI to suggest code while you're
 With Code Suggestions, you get:
 
 - Code Completion, which suggests completions the current line you are typing. These suggestions are usually low latency.
-- Code Generation, which generates code based on a natural language code comment block. Generating code can exceed multiple seconds.
+- Code Generation, which generates code based on a natural language code comment block. Responses for code generation are streamed in VS Code to begin giving results quickly. In other IDEs, response time can exceed multiple seconds.
 
 ## Start using Code Suggestions
 
@@ -81,18 +81,13 @@ plugin support. Refer to the JetBrains documentation for specifics on your IDE.
 
 Code Suggestions supports a variety of popular editors including:
 
-- VS Code, using [the VS Code GitLab Workflow extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow).
+- VS Code, using [the VS Code GitLab Workflow extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow). Supports streaming responses for code generation.
 - [GitLab WebIDE (VS Code in the Cloud)](../../../project/web_ide/index.md), with no additional configuration.
 - Microsoft Visual Studio, using the [Visual Studio GitLab extension](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio).
 - JetBrains IDEs, using the [GitLab plugin](https://plugins.jetbrains.com/plugin/22325-gitlab).
 - Neovim, using the [`gitlab.vim` plugin](https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim).
 
-A [GitLab Language Server for Code Suggestions](https://gitlab.com/gitlab-org/editor-extensions/gitlab-language-server-for-code-suggestions)
-is also in process.
-This improvement should result in:
-
-- Faster iteration and standardization of the IDE extensions.
-- The ability to use Code Suggestions even when an official editor extension isn't available.
+A [GitLab Language Server](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp) is used in VS Code, Visual Studio, and Neovim. The Language Server supports faster iteration across more platforms. Users can also configure it to support Code Suggestions in IDEs where GitLab doesn't provide official support.
 
 ## Code Suggestions data usage
 
@@ -120,7 +115,7 @@ For self-managed instances that have enabled Code Suggestions and SaaS accounts,
 
 ### Inference window context
 
-Code Suggestions inferences against the currently opened file, the content before and after the cursor, the filename, and the extension type. For more information on possible future context expansion to improve the quality of suggestions, see [epic 11669](https://gitlab.com/groups/gitlab-org/-/epics/11669).
+Code Suggestions inferences against the currently opened file, the content before and after the cursor, the file name, and the extension type. For more information on possible future context expansion to improve the quality of suggestions, see [epic 11669](https://gitlab.com/groups/gitlab-org/-/epics/11669).
 
 ### Training data