Add latest changes from gitlab-org/gitlab@master

15 files changed, 195 insertions, 86 deletions

diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md
index 448becb32dc..3d4f39b5ff0 100644
--- a/doc/administration/server_hooks.md
+++ b/doc/administration/server_hooks.md
@@ -47,15 +47,30 @@ To create server hooks for a repository:
      `pre-receive` server hook, the filename should be `pre-receive` with no extension.
    - To create many server hooks, create a directory for the hooks that matches the hook type. For example, for a
      `pre-receive` server hook, the directory name should be `pre-receive.d`. Put the files for the hook in that directory.
-1. Make the server hook files executable and ensure that they are owned by the Git user.
+1. **Make the server hook files executable** and ensure that they are owned by the Git user.
 1. Write the code to make the server hook function as expected. Git server hooks can be in any programming language. Ensure
    the [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) at the top reflects the language type. For
    example, if the script is in Ruby the shebang is probably `#!/usr/bin/env ruby`.
-1. Make the hook file executable, ensure that it's owned by the Git user, and ensure it does not match the backup file
+1. Ensure the hook file does not match the backup file
    pattern (`*~`).
 
 If the server hook code is properly implemented, it should execute when the Git hook is next triggered.
 
+### Gitaly Cluster
+
+If you use [Gitaly Cluster](gitaly/index.md), the scripts must be copied to every Gitaly node that has a replica of the repository. Every Gitaly node
+needs a copy because any node can be made a primary at any time. Server hooks only run on primary nodes.
+
+The location to copy the scripts to depends on where repositories are stored:
+
+- In GitLab 15.2 and earlier, Gitaly Cluster uses the [hashed storage path](repository_storage_types.md#hashed-storage)
+  reported by the GitLab application.
+- In GitLab 15.3 and later, new repositories are created using
+  [Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths-gitlab-150-and-later),
+  which are not the hashed storage path. The replica path can be identified by
+  [querying the Praefect repository metadata](../administration/gitaly/troubleshooting.md#view-repository-metadata)
+  using `-relative-path` to specify the expected GitLab hashed storage path.
+
 ## Create global server hooks for all repositories
 
 To create a Git hook that applies to all repositories, set a global server hook. Global server hooks also apply to:
diff --git a/doc/api/bulk_imports.md b/doc/api/bulk_imports.md
index e18a77df6df..1e0096a6bdd 100644
--- a/doc/api/bulk_imports.md
+++ b/doc/api/bulk_imports.md
@@ -33,6 +33,7 @@ POST /bulk_imports
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/bulk_imports" \
+  --header "Content-Type: application/json" \
   --data '{
     "configuration": {
       "url": "http://gitlab.example/",
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 1b606cc50bf..2d2b1d7adcd 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -20666,6 +20666,34 @@ Represents a milestone widget.
 | <a id="workitemwidgetmilestonemilestone"></a>`milestone` | [`Milestone`](#milestone) | Milestone of the work item. |
 | <a id="workitemwidgetmilestonetype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
 
+### `WorkItemWidgetNotes`
+
+Represents a notes widget.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="workitemwidgetnotestype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
+
+#### Fields with arguments
+
+##### `WorkItemWidgetNotes.discussions`
+
+Notes on this work item.
+
+Returns [`DiscussionConnection`](#discussionconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="workitemwidgetnotesdiscussionsfilter"></a>`filter` | [`NotesFilterType`](#notesfiltertype) | Type of notes collection: ALL_NOTES, ONLY_COMMENTS, ONLY_ACTIVITY. |
+
 ### `WorkItemWidgetStartAndDueDate`
 
 Represents a start and due date widget.
@@ -22025,6 +22053,16 @@ Kind of the network policy.
 | <a id="networkpolicykindciliumnetworkpolicy"></a>`CiliumNetworkPolicy` | Policy kind of Cilium Network Policy. |
 | <a id="networkpolicykindnetworkpolicy"></a>`NetworkPolicy` | Policy kind of Network Policy. |
 
+### `NotesFilterType`
+
+Work item notes collection type.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="notesfiltertypeall_notes"></a>`ALL_NOTES` | Show all activity. |
+| <a id="notesfiltertypeonly_activity"></a>`ONLY_ACTIVITY` | Show history only. |
+| <a id="notesfiltertypeonly_comments"></a>`ONLY_COMMENTS` | Show comments only. |
+
 ### `OncallRotationUnitEnum`
 
 Rotation length unit of an on-call rotation.
@@ -22816,6 +22854,7 @@ Type of a work item widget.
 | <a id="workitemwidgettypeiteration"></a>`ITERATION` | Iteration widget. |
 | <a id="workitemwidgettypelabels"></a>`LABELS` | Labels widget. |
 | <a id="workitemwidgettypemilestone"></a>`MILESTONE` | Milestone widget. |
+| <a id="workitemwidgettypenotes"></a>`NOTES` | Notes widget. |
 | <a id="workitemwidgettypestart_and_due_date"></a>`START_AND_DUE_DATE` | Start And Due Date widget. |
 | <a id="workitemwidgettypestatus"></a>`STATUS` | Status widget. |
 | <a id="workitemwidgettypeweight"></a>`WEIGHT` | Weight widget. |
@@ -24111,6 +24150,7 @@ Implementations:
 - [`WorkItemWidgetIteration`](#workitemwidgetiteration)
 - [`WorkItemWidgetLabels`](#workitemwidgetlabels)
 - [`WorkItemWidgetMilestone`](#workitemwidgetmilestone)
+- [`WorkItemWidgetNotes`](#workitemwidgetnotes)
 - [`WorkItemWidgetStartAndDueDate`](#workitemwidgetstartandduedate)
 - [`WorkItemWidgetStatus`](#workitemwidgetstatus)
 - [`WorkItemWidgetWeight`](#workitemwidgetweight)
diff --git a/doc/development/database/adding_database_indexes.md b/doc/development/database/adding_database_indexes.md
index d4cd807ef22..053747bac8c 100644
--- a/doc/development/database/adding_database_indexes.md
+++ b/doc/development/database/adding_database_indexes.md
@@ -107,11 +107,10 @@ determining whether existing indexes are still required. More information on
 the meaning of the various columns can be found at
 <https://www.postgresql.org/docs/current/monitoring-stats.html>.
 
-To determine if an index is still being used on production, use the following
-Thanos query with your index name:
+To determine if an index is still being used on production, use [Thanos](https://thanos-query.ops.gitlab.net/graph?g0.expr=sum%20by%20(type)(rate(pg_stat_user_indexes_idx_scan%7Benv%3D%22gprd%22%2C%20indexrelname%3D%22INSERT%20INDEX%20NAME%20HERE%22%7D%5B30d%5D))&g0.tab=1&g0.stacked=0&g0.range_input=1h&g0.max_source_resolution=0s&g0.deduplicate=1&g0.partial_response=0&g0.store_matches=%5B%5D):
 
 ```sql
-sum(rate(pg_stat_user_indexes_idx_tup_read{env="gprd", indexrelname="index_ci_name", type="patroni-ci"}[5m]))
+sum by (type)(rate(pg_stat_user_indexes_idx_scan{env="gprd", indexrelname="INSERT INDEX NAME HERE"}[30d]))
 ```
 
 Because the query output relies on the actual usage of your database, it
diff --git a/doc/development/database/database_dictionary.md b/doc/development/database/database_dictionary.md
index 474a6cbe093..afbd9a5aba8 100644
--- a/doc/development/database/database_dictionary.md
+++ b/doc/development/database/database_dictionary.md
@@ -30,14 +30,14 @@ milestone: '13.0'
 
 ## Schema
 
-| Attribute            | Type          | Required | Description                                                              |
-|----------------------|---------------|----------|--------------------------------------------------------------------------|
-| `table_name`         | String        | yes      | Database table name                                                      |
-| `classes`            | Array(String) | no       | List of classes that respond to `.table_name` with the `table_name`      |
-| `feature_categories` | Array(String) | yes      | List of feature categories using this table                              |
-| `description`        | String        | no       | Text description of the information stored in the table and it's purpose |
-| `introduced_by_url`  | URL           | no       | URL to the merge request or commit which introduced this table           |
-| `milestone`          | String        | no       | The milestone that introduced this table                                 |
+| Attribute                  | Type          | Required | Description                                                                       |
+|----------------------------|---------------|----------|-----------------------------------------------------------------------------------|
+| `table_name` / `view_name` | String        | yes      | Database table name or view name                                                  |
+| `classes`                  | Array(String) | no       | List of classes that are associated to this table or view.                        |
+| `feature_categories`       | Array(String) | yes      | List of feature categories using this table or view.                              |
+| `description`              | String        | no       | Text description of the information stored in the table or view, and its purpose. |
+| `introduced_by_url`        | URL           | no       | URL to the merge request or commit which introduced this table or view.           |
+| `milestone`                | String        | no       | The milestone that introduced this table or view.                                 |
 
 ## Adding tables
 
@@ -52,3 +52,20 @@ Include this file in the commit with the migration that creates the table.
 When dropping a table, you must remove the metadata file from `db/docs/` for `main` and `ci` databases.
 For the `geo` database, you must remove the file from `ee/db/docs/`.
 Use the same commit with the migration that drops the table.
+
+## Adding views
+
+When adding a new view, you should:
+
+1. Create a new file for this view in the appropriate directory:
+   - `main` database: `db/docs/views/`
+   - `ci` database: `db/docs/views/`
+   - `geo` database: `ee/db/docs/views/`
+1. Name the file `<view_name>.yml`, and include as much information as you know about the view.
+1. Include this file in the commit with the migration that creates the view.
+
+## Dropping views
+
+When dropping a view, you must remove the metadata file from `db/docs/views/`.
+For the `geo` database, you must remove the file from `ee/db/docs/views/`.
+Use the same commit with the migration that drops the view.
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index faf49b26788..6e505fa0d19 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -611,10 +611,10 @@ class MyMigration < Gitlab::Database::Migration[2.0]
 end
 ```
 
-Verify the index is not being used anymore with this Thanos query:
+You can verify that the index is not being used with [Thanos](https://thanos-query.ops.gitlab.net/graph?g0.expr=sum%20by%20(type)(rate(pg_stat_user_indexes_idx_scan%7Benv%3D%22gprd%22%2C%20indexrelname%3D%22INSERT%20INDEX%20NAME%20HERE%22%7D%5B30d%5D))&g0.tab=1&g0.stacked=0&g0.range_input=1h&g0.max_source_resolution=0s&g0.deduplicate=1&g0.partial_response=0&g0.store_matches=%5B%5D):
 
 ```sql
-sum by (type)(rate(pg_stat_user_indexes_idx_scan{env="gprd", indexrelname="index_groups_on_parent_id_id"}[5m]))
+sum by (type)(rate(pg_stat_user_indexes_idx_scan{env="gprd", indexrelname="INSERT INDEX NAME HERE"}[30d]))
 ```
 
 Note that it is not necessary to check if the index exists prior to
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 56bbcb815d1..87d8d493512 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -522,7 +522,7 @@ it('waits for an event', () => {
 
 ### Ensuring that tests are isolated
 
-Tests are normally architected in a pattern which requires a recurring setup and breakdown of the component under test. This is done by making use of the `beforeEach` and `afterEach` hooks.
+Tests are normally architected in a pattern which requires a recurring setup of the component under test. This is often achieved by making use of the `beforeEach` hook.
 
 Example
 
@@ -532,16 +532,22 @@ Example
   beforeEach(() => {
     wrapper = mount(Component);
   });
+```
+
+With [enableAutoDestroy](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/100389), it is no longer neccessary to manually call `wrapper.destroy()`.
+However, some mocks, spies, and fixtures do need to be torn down, and we can leverage the `afterEach` hook.
+
+Example
+
+```javascript
+  let wrapper;
 
   afterEach(() => {
-    wrapper.destroy();
+    fakeApollo = null;
+    store = null;
   });
 ```
 
-When looking at this initially you'd suspect that the component is setup before each test and then broken down afterwards, providing isolation between tests.
-
-This is however not entirely true as the `destroy` method does not remove everything which has been mutated on the `wrapper` object. For functional components, destroy only removes the rendered DOM elements from the document.
-
 ### Jest best practices
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34209) in GitLab 13.2.
diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md
index bb2f651786c..015fd9fc720 100644
--- a/doc/topics/offline/quick_start_guide.md
+++ b/doc/topics/offline/quick_start_guide.md
@@ -205,3 +205,13 @@ users are on the most up-to-date instances of GitLab. These two services can be
 environments so that they do not attempt and fail to reach out to GitLab services.
 
 Learn more about [disabling usage statistics](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics).
+
+### Configure NTP
+
+In GitLab 15.4 and 15.5, Gitaly Cluster doesn't function if `pool.ntp.org` is unreachable.
+[Customize the time server setting](../../administration/gitaly/praefect.md#customize-time-server-setting) on the Gitaly
+and Praefect servers so they can use an accessible NTP server.
+
+On offline instances, the [GitLab Geo check Rake task](../../administration/geo/replication/troubleshooting.md#can-geo-detect-the-current-site-correctly)
+always fails because it uses `pool.ntp.org`. This error can be ignored but you can
+[read more about how to work around it](../../administration/geo/replication/troubleshooting.md#message-machine-clock-is-synchronized--exception).
diff --git a/doc/update/index.md b/doc/update/index.md
index 29b6a1fc9c2..84dfcdeea95 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -506,6 +506,8 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
     sidekiq['routing_rules'] = [['*', 'default']]
     ```
 
+- New Git repositories created in Gitaly cluster [no longer use the `@hashed` storage path](#change-to-praefect-generated-replica-paths-in-gitlab-153). Server
+  hooks for new repositories must be copied into a different location.
 - The structure of `/etc/gitlab/gitlab-secrets.json` was modified in [GitLab 15.4](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6310),
   and new configuration was added to `gitlab_pages`, `grafana`, and `mattermost` sections.
   In a highly available or GitLab Geo environment, secrets need to be the same on all nodes.
@@ -521,6 +523,8 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 
 - [Incorrect deletion of object storage files on Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/371397) can occur in certain situations. See [Geo: Incorrect object storage LFS file deletion on secondary site issue in GitLab 15.0.0 to 15.3.2](#geo-incorrect-object-storage-lfs-file-deletion-on-secondary-sites-in-gitlab-1500-to-1532).
 - LFS transfers can [redirect to the primary from secondary site mid-session](https://gitlab.com/gitlab-org/gitlab/-/issues/371571) causing failed pull and clone requests when [Geo proxying](../administration/geo/secondary_proxy/index.md) is enabled. Geo proxying is enabled by default in GitLab 15.1 and later. See [Geo: LFS transfer redirect to primary from secondary site mid-session issue in GitLab 15.1.0 to 15.3.2](#geo-lfs-transfers-redirect-to-primary-from-secondary-site-mid-session-in-gitlab-1510-to-1532) for more details.
+- New Git repositories created in Gitaly cluster [no longer use the `@hashed` storage path](#change-to-praefect-generated-replica-paths-in-gitlab-153). Server
+  hooks for new repositories must be copied into a different location.
 
 ### 15.2.0
 
@@ -1197,6 +1201,19 @@ After upgraded to 11.11.8 you can safely upgrade to 12.0.Z.
 See our [documentation on upgrade paths](../policy/maintenance.md#upgrade-recommendations)
 for more information.
 
+### Change to Praefect-generated replica paths in GitLab 15.3
+
+New Git repositories created in Gitaly cluster no longer use the `@hashed` storage path.
+
+Praefect now generates replica paths for use by Gitaly cluster.
+This change is a pre-requisite for Gitaly cluster atomically creating, deleting, and
+renaming Git repositories.
+
+To identify the replica path, [query the Praefect repository metadata](../administration/gitaly/troubleshooting.md#view-repository-metadata)
+and pass the `@hashed` storage path to `-relative-path`.
+
+With this information, you can correctly install [server hooks](../administration/server_hooks.md).
+
 ### Maintenance mode issue in GitLab 13.9 to 14.4
 
 When [Maintenance mode](../administration/maintenance_mode/index.md) is enabled, users cannot sign in with SSO, SAML, or LDAP.
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md
index 03eed6fdbf8..b14a42a7fb0 100644
--- a/doc/user/application_security/api_fuzzing/index.md
+++ b/doc/user/application_security/api_fuzzing/index.md
@@ -1551,13 +1551,13 @@ When testing an API it can be useful to exclude certain paths. For example, you
 To verify the paths are excluded, review the `Tested Operations` and `Excluded Operations` portion of the job output. You should not see any excluded paths listed under `Tested Operations`.
 
 ```plaintext
-2021-05-27 21:51:08 [INF] API Security: --[ Tested Operations ]-------------------------
-2021-05-27 21:51:08 [INF] API Security: 201 POST http://target:7777/api/users CREATED
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
-2021-05-27 21:51:08 [INF] API Security: --[ Excluded Operations ]-----------------------
-2021-05-27 21:51:08 [INF] API Security: GET http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: POST http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: --[ Tested Operations ]-------------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: 201 POST http://target:7777/api/users CREATED
+2021-05-27 21:51:08 [INF] API Fuzzing: ------------------------------------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: --[ Excluded Operations ]-----------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: GET http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] API Fuzzing: POST http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] API Fuzzing: ------------------------------------------------
 ```
 
 #### Examples of excluding paths
@@ -1821,13 +1821,13 @@ As an alternative to excluding by paths, you can filter by any other component i
 In your job output you can check if any URLs matched any provided regular expression from `FUZZAPI_EXCLUDE_URLS`. Matching operations are listed in the **Excluded Operations** section. Operations listed in the **Excluded Operations** should not be listed in the **Tested Operations** section. For example the following portion of a job output:
 
 ```plaintext
-2021-05-27 21:51:08 [INF] API Security: --[ Tested Operations ]-------------------------
-2021-05-27 21:51:08 [INF] API Security: 201 POST http://target:7777/api/users CREATED
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
-2021-05-27 21:51:08 [INF] API Security: --[ Excluded Operations ]-----------------------
-2021-05-27 21:51:08 [INF] API Security: GET http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: POST http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: --[ Tested Operations ]-------------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: 201 POST http://target:7777/api/users CREATED
+2021-05-27 21:51:08 [INF] API Fuzzing: ------------------------------------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: --[ Excluded Operations ]-----------------------
+2021-05-27 21:51:08 [INF] API Fuzzing: GET http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] API Fuzzing: POST http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] API Fuzzing: ------------------------------------------------
 ```
 
 NOTE:
@@ -2242,18 +2242,18 @@ The first step to resolving performance issues is to understand what is contribu
 The API Fuzzing job output contains helpful information about how fast we are testing, how fast each operation being tested responds, and summary information. Let's take a look at some sample output to see how it can be used in tracking down performance issues:
 
 ```shell
-API Security: Loaded 10 operations from: assets/har-large-response/large_responses.har
-API Security:
-API Security: Testing operation [1/10]: 'GET http://target:7777/api/large_response_json'.
-API Security:  - Parameters: (Headers: 4, Query: 0, Body: 0)
-API Security:  - Request body size: 0 Bytes (0 bytes)
-API Security:
-API Security: Finished testing operation 'GET http://target:7777/api/large_response_json'.
-API Security:  - Excluded Parameters: (Headers: 0, Query: 0, Body: 0)
-API Security:  - Performed 767 requests
-API Security:  - Average response body size: 130 MB
-API Security:  - Average call time: 2 seconds and 82.69 milliseconds (2.082693 seconds)
-API Security:  - Time to complete: 14 minutes, 8 seconds and 788.36 milliseconds (848.788358 seconds)
+API Fuzzing: Loaded 10 operations from: assets/har-large-response/large_responses.har
+API Fuzzing:
+API Fuzzing: Testing operation [1/10]: 'GET http://target:7777/api/large_response_json'.
+API Fuzzing:  - Parameters: (Headers: 4, Query: 0, Body: 0)
+API Fuzzing:  - Request body size: 0 Bytes (0 bytes)
+API Fuzzing:
+API Fuzzing: Finished testing operation 'GET http://target:7777/api/large_response_json'.
+API Fuzzing:  - Excluded Parameters: (Headers: 0, Query: 0, Body: 0)
+API Fuzzing:  - Performed 767 requests
+API Fuzzing:  - Average response body size: 130 MB
+API Fuzzing:  - Average call time: 2 seconds and 82.69 milliseconds (2.082693 seconds)
+API Fuzzing:  - Time to complete: 14 minutes, 8 seconds and 788.36 milliseconds (848.788358 seconds)
 ```
 
 This job console output snippet starts by telling us how many operations were found (10), followed by notifications that testing has started on a specific operation and a summary of the operation has been completed. The summary is the most interesting part of this log output. In the summary, we can see that it took API Fuzzing 767 requests to fully test this operation and its related fields. We can also see that the average response time was 2 seconds and the time to complete was 14 minutes for this one operation.
@@ -2443,7 +2443,7 @@ See the following documentation sections for assistance:
 
 See [Performance Tuning and Testing Speed](#performance-tuning-and-testing-speed)
 
-### Error waiting for API Security 'http://127.0.0.1:5000' to become available
+### Error waiting for API Fuzzing 'http://127.0.0.1:5000' to become available
 
 A bug exists in versions of the API Fuzzing analyzer prior to v1.6.196 that can cause a background process to fail under certain conditions. The solution is to update to a newer version of the API Fuzzing analyzer.
 
@@ -2456,6 +2456,11 @@ If the issue is occurring with versions v1.6.196 or greater, contact Support and
 1. The `gl-api-security-scanner.log` file available as a job artifact. In the right-hand panel of the job details page, select the **Browse** button.
 1. The `apifuzzer_fuzz` job definition from your `.gitlab-ci.yml` file.
 
+**Error message**
+
+- In [GitLab 15.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/376078), `Error waiting for API Fuzzing 'http://127.0.0.1:5000' to become available`
+- In GitLab 15.5 and earlier, `Error waiting for API Security 'http://127.0.0.1:5000' to become available`.
+
 ### `Failed to start session with scanner. Please retry, and if the problem persists reach out to support.`
 
 The API Fuzzing engine outputs an error message when it cannot establish a connection with the scanner application component. The error message is shown in the job output window of the `apifuzzer_fuzz` job. A common cause for this issue is that the background component cannot use the selected port as it's already in use. This error can occur intermittently if timing plays a part (race condition). This issue occurs most often with Kubernetes environments when other services are mapped into the container causing port conflicts.
diff --git a/doc/user/application_security/dast_api/index.md b/doc/user/application_security/dast_api/index.md
index d77be0f0ca9..996338d54c4 100644
--- a/doc/user/application_security/dast_api/index.md
+++ b/doc/user/application_security/dast_api/index.md
@@ -1497,13 +1497,13 @@ When testing an API it can be useful to exclude certain paths. For example, you
 To verify the paths are excluded, review the `Tested Operations` and `Excluded Operations` portion of the job output. You should not see any excluded paths listed under `Tested Operations`.
 
 ```plaintext
-2021-05-27 21:51:08 [INF] API Security: --[ Tested Operations ]-------------------------
-2021-05-27 21:51:08 [INF] API Security: 201 POST http://target:7777/api/users CREATED
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
-2021-05-27 21:51:08 [INF] API Security: --[ Excluded Operations ]-----------------------
-2021-05-27 21:51:08 [INF] API Security: GET http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: POST http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
+2021-05-27 21:51:08 [INF] DAST API: --[ Tested Operations ]-------------------------
+2021-05-27 21:51:08 [INF] DAST API: 201 POST http://target:7777/api/users CREATED
+2021-05-27 21:51:08 [INF] DAST API: ------------------------------------------------
+2021-05-27 21:51:08 [INF] DAST API: --[ Excluded Operations ]-----------------------
+2021-05-27 21:51:08 [INF] DAST API: GET http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] DAST API: POST http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] DAST API: ------------------------------------------------
 ```
 
 ### Examples
@@ -1780,13 +1780,13 @@ As an alternative to excluding by paths, you can filter by any other component i
 In your job output you can check if any URLs matched any provided regular expression from `DAST_API_EXCLUDE_URLS`. Matching operations are listed in the **Excluded Operations** section. Operations listed in the **Excluded Operations** should not be listed in the **Tested Operations** section. For example the following portion of a job output:
 
 ```plaintext
-2021-05-27 21:51:08 [INF] API Security: --[ Tested Operations ]-------------------------
-2021-05-27 21:51:08 [INF] API Security: 201 POST http://target:7777/api/users CREATED
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
-2021-05-27 21:51:08 [INF] API Security: --[ Excluded Operations ]-----------------------
-2021-05-27 21:51:08 [INF] API Security: GET http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: POST http://target:7777/api/messages
-2021-05-27 21:51:08 [INF] API Security: ------------------------------------------------
+2021-05-27 21:51:08 [INF] DAST API: --[ Tested Operations ]-------------------------
+2021-05-27 21:51:08 [INF] DAST API: 201 POST http://target:7777/api/users CREATED
+2021-05-27 21:51:08 [INF] DAST API: ------------------------------------------------
+2021-05-27 21:51:08 [INF] DAST API: --[ Excluded Operations ]-----------------------
+2021-05-27 21:51:08 [INF] DAST API: GET http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] DAST API: POST http://target:7777/api/messages
+2021-05-27 21:51:08 [INF] DAST API: ------------------------------------------------
 ```
 
 NOTE:
@@ -2083,18 +2083,18 @@ The first step to resolving performance issues is to understand what is contribu
 The DAST API job output contains helpful information about how fast we are testing, how fast each operation being tested responds, and summary information. Let's take a look at some sample output to see how it can be used in tracking down performance issues:
 
 ```shell
-API Security: Loaded 10 operations from: assets/har-large-response/large_responses.har
-API Security:
-API Security: Testing operation [1/10]: 'GET http://target:7777/api/large_response_json'.
-API Security:  - Parameters: (Headers: 4, Query: 0, Body: 0)
-API Security:  - Request body size: 0 Bytes (0 bytes)
-API Security:
-API Security: Finished testing operation 'GET http://target:7777/api/large_response_json'.
-API Security:  - Excluded Parameters: (Headers: 0, Query: 0, Body: 0)
-API Security:  - Performed 767 requests
-API Security:  - Average response body size: 130 MB
-API Security:  - Average call time: 2 seconds and 82.69 milliseconds (2.082693 seconds)
-API Security:  - Time to complete: 14 minutes, 8 seconds and 788.36 milliseconds (848.788358 seconds)
+DAST API: Loaded 10 operations from: assets/har-large-response/large_responses.har
+DAST API:
+DAST API: Testing operation [1/10]: 'GET http://target:7777/api/large_response_json'.
+DAST API:  - Parameters: (Headers: 4, Query: 0, Body: 0)
+DAST API:  - Request body size: 0 Bytes (0 bytes)
+DAST API:
+DAST API: Finished testing operation 'GET http://target:7777/api/large_response_json'.
+DAST API:  - Excluded Parameters: (Headers: 0, Query: 0, Body: 0)
+DAST API:  - Performed 767 requests
+DAST API:  - Average response body size: 130 MB
+DAST API:  - Average call time: 2 seconds and 82.69 milliseconds (2.082693 seconds)
+DAST API:  - Time to complete: 14 minutes, 8 seconds and 788.36 milliseconds (848.788358 seconds)
 ```
 
 This job console output snippet starts by telling us how many operations were found (10), followed by notifications that testing has started on a specific operation and a summary of the operation has been completed. The summary is the most interesting part of this log output. In the summary, we can see that it took DAST API 767 requests to fully test this operation and its related fields. We can also see that the average response time was 2 seconds and the time to complete was 14 minutes for this one operation.
@@ -2281,7 +2281,7 @@ See the following documentation sections for assistance:
 
 See [Performance Tuning and Testing Speed](#performance-tuning-and-testing-speed)
 
-### Error waiting for API Security 'http://127.0.0.1:5000' to become available
+### Error waiting for DAST API 'http://127.0.0.1:5000' to become available
 
 A bug exists in versions of the DAST API analyzer prior to v1.6.196 that can cause a background process to fail under certain conditions. The solution is to update to a newer version of the DAST API analyzer.
 
@@ -2294,6 +2294,11 @@ If the issue is occurring with versions v1.6.196 or greater, contact Support and
 1. The `gl-api-security-scanner.log` file available as a job artifact. In the right-hand panel of the job details page, select the **Browse** button.
 1. The `dast_api` job definition from your `.gitlab-ci.yml` file.
 
+**Error message**
+
+- In [GitLab 15.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/376078), `Error waiting for DAST API 'http://127.0.0.1:5000' to become available`
+- In GitLab 15.5 and earlier, `Error waiting for API Security 'http://127.0.0.1:5000' to become available`.
+
 ### `Failed to start scanner session (version header not found)`
 
 The DAST API engine outputs an error message when it cannot establish a connection with the scanner application component. The error message is shown in the job output window of the `dast_api` job. A common cause of this issue is changing the `DAST_API_API` variable from its default.
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index d3d50ee1a8f..0adda54bf06 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -189,7 +189,7 @@ the default value [is the same as for self-managed instances](../admin_area/sett
 |-------------------------------|--------------------|
 | [Repository size including LFS](../admin_area/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB |
 | [Maximum import size](../project/settings/import_export.md#maximum-import-file-size)                        | 5 GB  |
-| Maximum attachment size       | 10 MB              |
+| 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)
diff --git a/doc/user/project/integrations/mlflow_client.md b/doc/user/project/integrations/mlflow_client.md
index 82bfd08e926..111037a63d7 100644
--- a/doc/user/project/integrations/mlflow_client.md
+++ b/doc/user/project/integrations/mlflow_client.md
@@ -49,7 +49,7 @@ that can be explored by selecting an experiment.
 
 - The API GitLab supports is the one defined at MLFlow version 1.28.0.
 - API endpoints not listed above are not supported.
-- During creation of experiments and runs, tags are ExperimentTags and RunTags are ignored.
+- During creation of experiments and runs, tags are ExperimentTags and RunTags are stored, even though they are not displayed.
 - MLFLow Model Registry is not supported.
 
 ## Supported methods and caveats
@@ -57,7 +57,7 @@ that can be explored by selecting an experiment.
 This is a list of methods we support from the MLFlow client. Other methods might be supported but were not
 tested. More information can be found in the [MLFlow Documentation](https://www.mlflow.org/docs/1.28.0/python_api/mlflow.html).
 
-### `set_experiment`
+### `set_experiment()`
 
 Accepts both experiment_name and experiment_id
 
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index 5819878d728..53c396fa9af 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -331,13 +331,8 @@ GitLab expects a response in [10 seconds](../../../user/gitlab_com/index.md#othe
 
 ### Re-enable disabled webhooks
 
-> Introduced in GitLab 15.2 [with a flag](../../../administration/feature_flags.md) named `webhooks_failed_callout`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available,
-ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `webhooks_failed_callout`.
-On GitLab.com, this feature is not available.
-The feature is not ready for production use.
+> - Introduced in GitLab 15.2 [with a flag](../../../administration/feature_flags.md) named `webhooks_failed_callout`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365535) in GitLab 15.7. Feature flag `webhooks_failed_callout` removed.
 
 If a webhook is failing, a banner displays at the top of the edit page explaining
 why it is disabled, and when it will be automatically re-enabled. For example:
diff --git a/doc/user/project/ml/experiment_tracking/index.md b/doc/user/project/ml/experiment_tracking/index.md
index e274bd7f38e..d7d737572e0 100644
--- a/doc/user/project/ml/experiment_tracking/index.md
+++ b/doc/user/project/ml/experiment_tracking/index.md
@@ -64,7 +64,6 @@ package registry. The package name for a candidate is `ml_candidate_<candidate_i
 ### Limitations and future
 
 - Searching experiments, searching trials, visual comparison of trials, and creating, deleting and updating experiments and trials through GitLab UI is under development.
-- No support for experiment and trial metadata that do not classify as parameters or metrics.
 
 ## Disabling or enabling the Feature