Add latest changes from gitlab-org/gitlab@master

18 files changed, 112 insertions, 72 deletions

diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index addf894f0a5..35ab1d8252c 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -165,6 +165,7 @@ It does not cover all data types.
 | LFS objects (using Git)                             | **{check-circle}** Yes |
 | Pages                                               | **{dotted-circle}** No <sup>2</sup> |
 | Advanced search (using the web UI)                  | **{dotted-circle}** No |
+| Container registry                                  | **{dotted-circle}** No |
 
 1. Git reads are served from the local secondary while pushes get proxied to the primary.
    Selective sync or cases where repositories don't exist locally on the Geo secondary throw a "not found" error.
diff --git a/doc/administration/operations/index.md b/doc/administration/operations/index.md
index f6ab46b9fbf..b02aab738ea 100644
--- a/doc/administration/operations/index.md
+++ b/doc/administration/operations/index.md
@@ -8,6 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Keep your GitLab instance up and running smoothly.
 
+- [Upgrading GitLab](../../update/index.md).
 - [Rake tasks](../../raketasks/index.md): Tasks for common administration and operational processes such as
   [cleaning up unneeded items from GitLab instance](../../raketasks/cleanup.md), integrity checks,
   and more.
diff --git a/doc/administration/postgresql/multiple_databases.md b/doc/administration/postgresql/multiple_databases.md
index 9ac4448a004..188578a739c 100644
--- a/doc/administration/postgresql/multiple_databases.md
+++ b/doc/administration/postgresql/multiple_databases.md
@@ -1,6 +1,6 @@
 ---
 stage: Data Stores
-group: Pods
+group: Tenant Scale
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/api/pipeline_triggers.md b/doc/api/pipeline_triggers.md
index 1ffda1c0d79..50acac6bc2a 100644
--- a/doc/api/pipeline_triggers.md
+++ b/doc/api/pipeline_triggers.md
@@ -155,7 +155,7 @@ or a [CI/CD job token](../ci/jobs/ci_job_token.md) for authentication.
 
 With a CI/CD job token, the [triggered pipeline is a multi-project pipeline](../ci/pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api).
 The job that authenticates the request becomes associated with the upstream pipeline,
-which is visible on the [pipeline graph](../ci/pipelines/downstream_pipelines.md#view-multi-project-pipelines-in-pipeline-graphs).
+which is visible on the pipeline graph.
 
 If you use a trigger token in a job, the job is not associated with the upstream pipeline.
 
diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md
index 8031ce751ec..1e4654e69fe 100644
--- a/doc/ci/pipelines/downstream_pipelines.md
+++ b/doc/ci/pipelines/downstream_pipelines.md
@@ -315,18 +315,32 @@ trigger_pipeline:
 > Hover behavior for pipeline cards [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) in GitLab 13.2.
 
 In the [pipeline graph view](index.md#view-full-pipeline-graph), downstream pipelines display
-as a list of cards on the right of the graph. Hover over the pipeline's card to view
-which job triggered the downstream pipeline.
+as a list of cards on the right of the graph. From this view, you can:
 
-### Retry a downstream pipeline
+- Select a trigger job to see the triggered downstream pipeline's jobs.
+- Select **Expand jobs** **{chevron-lg-right}** on a pipeline card to expand the view
+  with the downstream pipeline's jobs. You can view one downstream pipeline at a time.
+- Hover over a pipeline card to have the job that triggered the downstream pipeline highlighted.
+
+### Retry failed and canceled jobs in a downstream pipeline
 
 > - Retry from graph view [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/354974) in GitLab 15.0 [with a flag](../../administration/feature_flags.md) named `downstream_retry_action`. Disabled by default.
 > - Retry from graph view [generally available and feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/357406) in GitLab 15.1.
 
-To retry a completed downstream pipeline, select **Retry** (**{retry}**):
+To retry failed and canceled jobs, select **Retry** (**{retry}**):
 
 - From the downstream pipeline's details page.
-- On the pipeline's card in the [pipeline graph view](index.md#view-full-pipeline-graph).
+- On the pipeline's card in the pipeline graph view.
+
+### Recreate a downstream pipeline
+
+> Retry trigger job from graph view [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367547) in GitLab 15.10 [with a flag](../../administration/feature_flags.md) named `ci_recreate_downstream_pipeline`. Disabled by default.
+
+You can recreate a downstream pipeline by retrying its corresponding trigger job. The newly created downstream pipeline replaces the current downstream pipeline in the pipeline graph.
+
+To recreate a downstream pipeline:
+
+- Select **Run again** (**{retry}**) on the trigger job's card in the pipeline graph view.
 
 ### Cancel a downstream pipeline
 
@@ -336,7 +350,7 @@ To retry a completed downstream pipeline, select **Retry** (**{retry}**):
 To cancel a downstream pipeline that is still running, select **Cancel** (**{cancel}**):
 
 - From the downstream pipeline's details page.
-- On the pipeline's card in the [pipeline graph view](index.md#view-full-pipeline-graph).
+- On the pipeline's card in the pipeline graph view.
 
 ### Mirror the status of a downstream pipeline in the trigger job
 
@@ -371,13 +385,9 @@ trigger_job:
 After you trigger a multi-project pipeline, the downstream pipeline displays
 to the right of the [pipeline graph](index.md#visualize-pipelines).
 
-![Multi-project pipeline graph](img/multi_project_pipeline_graph_v14_3.png)
-
 In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipeline
 displays to the right of the mini graph.
 
-![Multi-project pipeline mini graph](img/pipeline_mini_graph_v15_0.png)
-
 ## Fetch artifacts from an upstream pipeline
 
 Use [`needs:project`](../yaml/index.md#needsproject) to fetch artifacts from an
diff --git a/doc/ci/pipelines/img/multi_project_pipeline_graph_v14_3.png b/doc/ci/pipelines/img/multi_project_pipeline_graph_v14_3.png
deleted file mode 100644
index aadf8bb0979..00000000000
--- a/doc/ci/pipelines/img/multi_project_pipeline_graph_v14_3.png
+++ /dev/null
diff --git a/doc/ci/pipelines/img/pipeline_mini_graph_v15_0.png b/doc/ci/pipelines/img/pipeline_mini_graph_v15_0.png
deleted file mode 100644
index 48a0ca9d84f..00000000000
--- a/doc/ci/pipelines/img/pipeline_mini_graph_v15_0.png
+++ /dev/null
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index fa04cb6cb92..d2038dbcb62 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -423,8 +423,7 @@ You can group the jobs by:
 - [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
   jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
 
-[Multi-project pipeline graphs](downstream_pipelines.md#view-multi-project-pipelines-in-pipeline-graphs) help
-you visualize the entire pipeline, including all cross-project inter-dependencies.
+Multi-project pipeline graphs help you visualize the entire pipeline, including all cross-project inter-dependencies.
 
 If a stage contains more than 100 jobs, only the first 100 jobs are listed in the
 pipeline graph. The remaining jobs still run as usual. To see the jobs:
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 02350cf0d21..a1a4089a48b 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -961,10 +961,8 @@ job:
 
 #### `artifacts:public`
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49775) in GitLab 13.8
-> - It's [deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
-> - It's disabled on GitLab.com.
-> - It's recommended for production use.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223273) in GitLab 13.8 [with a flag](../../user/feature_flags.md) named `non_public_artifacts`, disabled by default.
+> - [Updated](https://gitlab.com/gitlab-org/gitlab/-/issues/322454) in GitLab 15.10. Artifacts created with `artifacts:public` before 15.10 are not guaranteed to remain private after this update.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available. To make it available,
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 36b38e2e16b..d24875e559a 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -30,7 +30,9 @@ We were using Overcommit prior to Lefthook, so you may want to uninstall it firs
 
 ### Install Lefthook
 
-1. Install the `lefthook` Ruby gem:
+1. You can install lefthook in [different ways](https://github.com/evilmartians/lefthook/blob/master/docs/install.md#install-lefthook).
+   If you do not choose to install it globally (e.g. via Homebrew or package managers), and only want to use it for the GitLab project,
+   you can install the Ruby gem via:
 
    ```shell
    bundle install
@@ -39,12 +41,18 @@ We were using Overcommit prior to Lefthook, so you may want to uninstall it firs
 1. Install Lefthook managed Git hooks:
 
    ```shell
+   # If installed globally
+   lefthook install
+   # Or if installed via ruby gem
    bundle exec lefthook install
    ```
 
 1. Test Lefthook is working by running the Lefthook `pre-push` Git hook:
 
    ```shell
+   # If installed globally
+   lefthook run pre-push
+   # Or if installed via ruby gem
    bundle exec lefthook run pre-push
    ```
 
@@ -57,6 +65,18 @@ Lefthook is configured with a combination of:
 - Project configuration in [`lefthook.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lefthook.yml).
 - Any [local configuration](https://github.com/evilmartians/lefthook/blob/master/README.md#local-config).
 
+### Lefthook auto-fixing files
+
+We have a custom lefthook target to run all the linters with auto-fix capabilities,
+but just on the files which changed in your branch.
+
+```shell
+# If installed globally
+lefthook run auto-fix
+# Or if installed via ruby gem
+bundle exec lefthook run auto-fix
+```
+
 ### Disable Lefthook temporarily
 
 To disable Lefthook temporarily, you can set the `LEFTHOOK` environment variable to `0`. For instance:
diff --git a/doc/development/database/multiple_databases.md b/doc/development/database/multiple_databases.md
index d22e3209096..c1b30a4cbbe 100644
--- a/doc/development/database/multiple_databases.md
+++ b/doc/development/database/multiple_databases.md
@@ -1,6 +1,6 @@
 ---
 stage: Data Stores
-group: Pods
+group: Tenant Scale
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/gemfile.md b/doc/development/gemfile.md
index bfe8b7c5205..fbdba2ecb23 100644
--- a/doc/development/gemfile.md
+++ b/doc/development/gemfile.md
@@ -60,6 +60,8 @@ This means that new dependencies should, at a minimum, meet the following criter
 - There are no issues open that we know may impact the availability or performance of GitLab.
 - The project is tested using some form of test automation. The test suite must be passing
   using the Ruby version currently used by GitLab.
+- CI builds for all supported platforms must succeed using the new dependency. For more information, see
+  how to [build a package for testing](build_test_package.md#building-a-package-for-testing).
 - If the project uses a C extension, consider requesting an additional review from a C or MRI
   domain expert. C extensions can greatly impact GitLab stability and performance.
 
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md
index f8021436c27..0b97bfd945a 100644
--- a/doc/integration/advanced_search/elasticsearch.md
+++ b/doc/integration/advanced_search/elasticsearch.md
@@ -662,6 +662,7 @@ For basic guidance on choosing a cluster configuration you may refer to [Elastic
 
 - Generally, you want to use at least a 2-node cluster configuration with one replica, which allows you to have resilience. If your storage usage is growing quickly, you may want to plan horizontal scaling (adding more nodes) beforehand.
 - It's not recommended to use HDD storage with the search cluster, because it takes a hit on performance. It's better to use SSD storage (NVMe or SATA SSD drives for example).
+- You should not use [coordinating-only nodes](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#coordinating-only-node) with large instances. Coordinating-only nodes are smaller than [data nodes](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#data-node), which can impact performance and advanced search migrations.
 - You can use the [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) to benchmark search performance with different search cluster sizes and configurations.
 - `Heap size` should be set to no more than 50% of your physical RAM. Additionally, it shouldn't be set to more than the threshold for zero-based compressed oops. The exact threshold varies, but 26 GB is safe on most systems, but can also be as large as 30 GB on some systems. See [Heap size settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#heap-size-settings) and [Setting JVM options](https://www.elastic.co/guide/en/elasticsearch/reference/current/jvm-options.html) for more details.
 - Number of CPUs (CPU cores) per node usually corresponds to the `Number of Elasticsearch shards` setting described below.
diff --git a/doc/update/index.md b/doc/update/index.md
index a7e1fd23b98..9c3d5840e75 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -196,11 +196,11 @@ accordingly, while also consulting the
 
 NOTE:
 When not explicitly specified, upgrade GitLab to the latest available patch
-release rather than the first patch release, for example `13.8.8` instead of `13.8.0`.
-This includes versions you must stop at on the upgrade path as there may
+release of the `major`.`minor` release rather than the first patch release, for example `13.8.8` instead of `13.8.0`.
+This includes `major`.`minor` versions you must stop at on the upgrade path as there may
 be fixes for issues relating to the upgrade process.
 Specifically around a [major version](#upgrading-to-a-new-major-version),
-crucial database schema and migration patches are included in the latest patch releases.
+crucial database schema and migration patches may be included in the latest patch releases.
 
 ## Upgrading between editions
 
@@ -237,7 +237,7 @@ possible.
 
 ## Version-specific upgrading instructions
 
-Each month, major, minor, or patch releases of GitLab are published along with a
+Each month, major or minor as well as possibly patch releases of GitLab are published along with a
 [release post](https://about.gitlab.com/releases/categories/releases/).
 You should read the release posts for all versions you're passing over.
 At the end of major and minor release posts, there are three sections to look for specifically:
@@ -267,7 +267,6 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 ### 15.9.0
 
 - There is a [database migration bug in GitLab 15.9.x](#user-profile-data-loss-bug-in-159x) that can cause data to be lost from the user profile fields. This bug affects all currently available 15.9.x releases. Until a bug fix is released, you should upgrade to 15.6.x, 15.7.x, or 15.8.x first.
-- This version removes `SanitizeConfidentialTodos` background migration [added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87908/diffs) in 15.6, which removed any user inaccessible to-do items. Make sure that this migration is finished before upgrading to 15.9.
 - As part of the [CI Partitioning effort](../architecture/blueprints/ci_data_decay/pipeline_partitioning.md), a [new Foreign Key](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107547) was added to `ci_builds_needs`. On GitLab instances with large CI tables, adding this constraint can take longer than usual. Make sure that this migration is finished before upgrading to 15.9.
 - Praefect's metadata verifier's [invalid metadata deletion behavior](../administration/gitaly/praefect.md#enable-deletions) is now enabled by default.
 
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index c44901b1ad7..3bf52bfe001 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -51,17 +51,26 @@ signing up using OmniAuth or LDAP, set `block_auto_created_users` to `true` in t
 [OmniAuth configuration](../../../integration/omniauth.md#configure-common-settings) or
 [LDAP configuration](../../../administration/auth/ldap/index.md#basic-configuration-settings).
 
-## Require email confirmation
+## Confirm user email
+
+> - Soft email confirmation [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2 [with a flag](../../../operations/feature_flags.md) named `soft_email_confirmation`.
+> - Soft email confirmation [changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107302/diffs) from a feature flag to an application setting in GitLab 15.9.
 
 You can send confirmation emails during sign up and require that users confirm
 their email address before they are allowed to sign in.
 
-To enforce confirmation of the email address used for new sign ups:
+For example, to enforce confirmation of the email address used for new sign ups:
 
 1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
 1. Under **Email confirmation settings**, select **Hard**.
 
+The following settings are available:
+
+- **Hard** - Send a confirmation email during sign up. New users must confirm their email address before they can log in.
+- **Soft** - Send a confirmation email during sign up. New users can log in immediately, but must confirm their email in three days. Unconfirmed accounts are deleted.
+- **Off** - New users can sign up without confirming their email address.
+
 ## User cap
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.7.
@@ -95,22 +104,6 @@ New user sign ups are subject to the user cap restriction.
 New users sign ups are not subject to the user cap restriction. Users in pending approval state are
 automatically approved in a background job.
 
-## Soft email confirmation
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2.
-> - It's [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
-> - It's enabled on GitLab.com.
-> - It's recommended for production use.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-soft-email-confirmation).
-
-WARNING:
-This feature might not be available to you. Check the **version history** note above for details.
-
-The soft email confirmation improves the sign-up experience for new users by allowing
-them to sign in without an immediate confirmation when an email confirmation is required.
-GitLab shows the user a reminder to confirm their email address, and the user can't
-create or update pipelines until their email address is confirmed.
-
 ## Minimum password length limit
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
@@ -171,25 +164,6 @@ semicolon, comma, or a new line.
 
    ![Domain Denylist](img/domain_denylist_v14_1.png)
 
-### Enable or disable soft email confirmation
-
-Soft email confirmation is under development but ready for production use.
-It is deployed behind a feature flag that is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:soft_email_confirmation)
-```
-
-To disable it:
-
-```ruby
-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.
diff --git a/doc/user/group/saml_sso/group_sync.md b/doc/user/group/saml_sso/group_sync.md
index ff6e906b144..7c9b6effc43 100644
--- a/doc/user/group/saml_sso/group_sync.md
+++ b/doc/user/group/saml_sso/group_sync.md
@@ -106,6 +106,30 @@ Users granted:
 
 SAML group membership is evaluated each time a user signs in.
 
+### Global SAML group memberships lock **(PREMIUM SELF)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386390) in GitLab 15.10.
+
+GitLab administrators can use the global SAML group memberships lock to prevent group members from inviting new members to subgroups that have their membership synchronized with SAML Group Links.
+
+Global group memberships lock only applies to subgroups of a top-level group where SAML Group Links synchronization is configured. No user can modify the
+membership of a top-level group configured for SAML Group Links synchronization.
+
+When global group memberships lock is enabled:
+
+- Only an administrator can manage memberships of any group including access levels.
+- Users cannot:
+  - Share a project with other groups.
+  - Invite members to a project created in a group.
+
+To enable global group memberships lock:
+
+1. [Configure SAML](../../../integration/saml.md) for your self-managed GitLab instance.
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Visibility and access controls** section.
+1. Ensure the **Lock memberships to SAML synchronization** checkbox is selected.
+
 ### Automatic member removal
 
 After a group sync, users who are not members of a mapped SAML group are removed from the group.
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index 7577a9446c8..9839f308a3a 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -266,19 +266,28 @@ The GitLab npm repository supports the following commands for the npm CLI (`npm`
 
 ### `404 Not Found` errors are happening on `npm install` or `yarn`
 
-Using `CI_JOB_TOKEN` to install npm packages with dependencies in another project gives you 404 Not Found errors. A fix for this problem is proposed in [issue 352962](https://gitlab.com/gitlab-org/gitlab/-/issues/352962).
+Using `CI_JOB_TOKEN` to install npm packages with dependencies in another project gives you 404 Not Found errors. You need to authenticate with a token that has access to the package and all its dependencies.
 
-As a workaround, you can:
+If the package and its dependencies are in separate projects but in the same group, you can use a
+[group deploy token](../../project/deploy_tokens/index.md#create-a-deploy-token):
 
-1. Create a [personal access token](../../profile/personal_access_tokens.md).
-1. Authenticate at both the instance level and project level for each package:
+```ini
+//gitlab.example.com/api/v4/packages/npm/:_authToken=<group-token>
+@group-scope:registry=https://gitlab.example.com/api/v4/packages/npm/
+```
 
-   ```ini
-   @foo:registry=https://gitlab.example.com/api/v4/packages/npm/
-   //gitlab.example.com/api/v4/packages/npm/:_authToken=${MY_TOKEN}
-   //gitlab.example.com/api/v4/projects/<your_project_id_a>/packages/npm/:_authToken=${MY_TOKEN}
-   //gitlab.example.com/api/v4/projects/<your_project_id_b>/packages/npm/:_authToken=${MY_TOKEN}
-   ```
+If the package and its dependencies are spread across multiple groups, you can use a [personal access token](../../profile/personal_access_tokens.md)
+from a user that has access to all the groups or individual projects:
+
+```ini
+//gitlab.example.com/api/v4/packages/npm/:_authToken=<personal-access-token>
+@group-1:registry=https://gitlab.example.com/api/v4/packages/npm/
+@group-2:registry=https://gitlab.example.com/api/v4/packages/npm/
+```
+
+WARNING:
+Personal access tokens must be treated carefully. Read our [token security considerations](../../../security/token_overview.md#security-considerations)
+for guidance on managing personal access tokens (for example, setting a short expiry and using minimal scopes).
 
 ### `npm publish` targets default npm registry (`registry.npmjs.org`)
 
diff --git a/doc/user/search/advanced_search.md b/doc/user/search/advanced_search.md
index 5273ea47f58..464c44a6f14 100644
--- a/doc/user/search/advanced_search.md
+++ b/doc/user/search/advanced_search.md
@@ -55,6 +55,8 @@ Advanced search uses [Elasticsearch syntax](https://www.elastic.co/guide/en/elas
 
 ### Refining user search
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/388409) in GitLab 15.10.
+
 In user search, a [fuzzy query](https://www.elastic.co/guide/en/elasticsearch/reference/7.2/query-dsl-fuzzy-query.html) is used by default. You can refine your search with [Elasticsearch syntax](#syntax).
 
 ### Code search