Add latest changes from gitlab-org/gitlab@master

8 files changed, 106 insertions, 38 deletions

diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 6e0254f4ed5..ec2cd6ba224 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -7779,6 +7779,7 @@ The connection type for [`Project`](#project).
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="projectconnectioncount"></a>`count` | [`Int!`](#int) | Total count of collection. |
 | <a id="projectconnectionedges"></a>`edges` | [`[ProjectEdge]`](#projectedge) | A list of edges. |
 | <a id="projectconnectionnodes"></a>`nodes` | [`[Project]`](#project) | A list of nodes. |
 | <a id="projectconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
diff --git a/doc/development/database/background_migrations.md b/doc/development/database/background_migrations.md
index 7519f7276b6..ab52dfad018 100644
--- a/doc/development/database/background_migrations.md
+++ b/doc/development/database/background_migrations.md
@@ -503,6 +503,6 @@ View the production Sidekiq log and filter for:
 - `json.meta.caller_id: <MyBackgroundMigrationSchedulingMigrationClassName>`
 - `json.args: <MyBackgroundMigrationClassName>`
 
-Looking at the `json.error_class`, `json.error_message` and `json.error_backtrace` values may be helpful in understanding why the jobs failed.
+Looking at the `json.exception.class`, `json.exception.message`, `json.exception.backtrace`, and `json.exception.sql` values may be helpful in understanding why the jobs failed.
 
 Depending on when and how the failure occurred, you may find other helpful information by filtering with `json.class: <MyBackgroundMigrationClassName>`.
diff --git a/doc/development/documentation/restful_api_styleguide.md b/doc/development/documentation/restful_api_styleguide.md
index 0a24f9b67be..1f270a2b5ee 100644
--- a/doc/development/documentation/restful_api_styleguide.md
+++ b/doc/development/documentation/restful_api_styleguide.md
@@ -41,12 +41,18 @@ Use the following template to help you get started. Be sure to list any
 required attributes first in the table.
 
 ````markdown
-## Descriptive title
+## API name
 
 > Version history note.
 
 One or two sentence description of what endpoint does.
 
+### Method title
+
+> Version history note.
+
+Description of the method.
+
 ```plaintext
 METHOD /endpoint
 ```
@@ -83,8 +89,40 @@ Example response:
 ```
 ````
 
-Adjust the [version history note accordingly](versions.md#add-a-version-history-item)
-to describe the GitLab release that introduced the API call.
+## Version history
+
+Add [version history](versions.md#documenting-version-specific-features)
+to describe new or updated API calls.
+
+To add version history for an individual attribute, include it in the version history
+for the section. For example:
+
+```markdown
+### Edit a widget
+
+> `widget_message` [introduced](<link-to-issue>) in GitLab 14.3.
+```
+
+## Attribute deprecation
+
+To deprecate an attribute:
+
+1. Add a version history note.
+
+   ```markdown
+   > - `widget_name` [deprecated](<link-to-issue>) in GitLab 14.7.
+   ```
+
+1. Add inline deprecation text to the description.
+
+   ```markdown
+   | Attribute     | Type   | Required               | Description                                  |
+   |:--------------|:-------|:-----------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------|
+   | `widget_name` | string | **{dotted-circle}** No | [Deprecated](<link-to-issue>) in GitLab 14.7 and is planned for removal in 15.4. Use `widget_id` instead. The name of the widget. |
+   ```
+
+1. Optional. To widely announce the change, or if it's a breaking change,
+   [update the deprecations and removals documentation](../deprecation_guidelines/#update-the-deprecations-and-removals-documentation).
 
 ## Method description
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index c1e6811732d..07c3c83912a 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -224,6 +224,16 @@ actors.
 Feature.enabled?(:some_feature, group)
 ```
 
+Multiple actors can be passed together in a comma-separated form:
+
+```shell
+/chatops run feature set --project=gitlab-org/gitlab,example-org/example-project some_feature true
+
+/chatops run feature set --group=gitlab-org,example-org some_feature true
+
+/chatops run feature set --namespace=gitlab-org,example-org some_feature true
+```
+
 Lastly, to verify that the feature is deemed stable in as many cases as possible,
 you should fully roll out the feature by enabling the flag **globally** by running:
 
diff --git a/doc/development/redis/new_redis_instance.md b/doc/development/redis/new_redis_instance.md
index 389cddbb4e5..4900755b58c 100644
--- a/doc/development/redis/new_redis_instance.md
+++ b/doc/development/redis/new_redis_instance.md
@@ -179,9 +179,12 @@ bin/feature-flag use_primary_store_as_default_for_foo
 By enabling `use_primary_and_secondary_stores_for_foo` feature flag, our `Gitlab::Redis::Foo` will use `MultiStore` to write to both new Redis instance
 and the [old (fallback-instance)](#fallback-instance).
 If we fail to fetch data from the new instance, we will fallback and read from the old Redis instance.
-
 We can monitor logs for `Gitlab::Redis::MultiStore::ReadFromPrimaryError`, and also the Prometheus counter `gitlab_redis_multi_store_read_fallback_total`.
-Once we stop seeing them, this means that we are no longer relying on the data stored on the old Redis store.
+
+For pipelined commands (`pipelined` and `multi`), we execute the entire operation in both stores and then compare the results. If they differ, we emit a
+`Gitlab::Redis::MultiStore:PipelinedDiffError` error, and track it in the `gitlab_redis_multi_store_pipelined_diff_error_total` Prometheus counter.
+
+Once we stop seeing those errors, this means that we are no longer relying on the data stored on the old Redis store.
 At this point, we are probably safe to move the traffic to the new Redis store.
 
 By enabling `use_primary_store_as_default_for_foo` feature flag, the `MultiStore` will use `primary_store` (new instance) as default Redis store.
@@ -213,6 +216,15 @@ MultiStore implements read and write Redis commands separately.
 - `del`
 - `pipelined`
 - `flushdb`
+- `rpush`
+
+##### Pipelined commands
+
+**NOTE:** The Ruby block passed to these commands will be executed twice, once per each store.
+Thus, excluding the Redis operations performed, the block should be idempotent.
+
+- `pipelined`
+- `multi`
 
 When a command outside of the supported list is used, `method_missing` will pass it to the old Redis instance and keep track of it.
 This ensures that anything unexpected behaves like it would before.
@@ -223,17 +235,19 @@ a developer will need to add an implementation for missing Redis commands before
 
 ##### Errors
 
-| error                                           | message                                                               |
-|-------------------------------------------------|-----------------------------------------------------------------------|
+| error                                             | message                                                                                     |
+|---------------------------------------------------|---------------------------------------------------------------------------------------------|
 | `Gitlab::Redis::MultiStore::ReadFromPrimaryError` | Value not found on the Redis primary store. Read from the Redis secondary store successful. |
-| `Gitlab::Redis::MultiStore::MethodMissingError`   | Method missing. Falling back to execute method on the Redis secondary store. |
+| `Gitlab::Redis::MultiStore::PipelinedDiffError`   | Pipelined command executed on both stores successfully but results differ between them.     |
+| `Gitlab::Redis::MultiStore::MethodMissingError`   | Method missing. Falling back to execute method on the Redis secondary store.                |
 
 ##### Metrics
 
-| metrics name                                    | type               | labels                 | description                                        |
-|-------------------------------------------------|--------------------|------------------------|----------------------------------------------------|
-| `gitlab_redis_multi_store_read_fallback_total`    | Prometheus Counter | command, instance_name | Client side Redis MultiStore reading fallback total|
-| `gitlab_redis_multi_store_method_missing_total`   | Prometheus Counter | command, instance_name | Client side Redis MultiStore method missing total  |
+| metrics name                                          | type               | labels                 | description                                            |
+|-------------------------------------------------------|--------------------|------------------------|--------------------------------------------------------|
+| `gitlab_redis_multi_store_read_fallback_total`        | Prometheus Counter | command, instance_name | Client side Redis MultiStore reading fallback total    |
+| `gitlab_redis_multi_store_pipelined_diff_error_total` | Prometheus Counter | command, instance_name | Redis MultiStore pipelined command diff between stores |
+| `gitlab_redis_multi_store_method_missing_total`       | Prometheus Counter | command, instance_name | Client side Redis MultiStore method missing total      |
 
 ## Step 4: clean up after the migration
 
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
index 33b392676ad..103eae07517 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -142,7 +142,9 @@ To restrict visibility levels for projects, snippets, and selected pages:
 1. In the **Restricted visibility levels** section, select the desired visibility levels to restrict.
    If you restrict the **Public** level:
    - User profiles are only visible to logged in users via the Web interface.
-   - User attributes are only visible to authenticated users via the GraphQL API.
+   - User attributes via the GraphQL API are:
+     - Not visible in [GitLab 15.1 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88020).
+     - Only visible to authenticated users between [GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33195) and GitLab 15.0.
 1. Select **Save changes**.
 
 For more details on project visibility, see
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index ac7d447961c..e4ce736684b 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -40,7 +40,9 @@ including:
 ## Group webhooks **(PREMIUM)**
 
 You can configure a group webhook, which is triggered by events
-that occur across all projects in the group.
+that occur across all projects in the group. If you configure identical webhooks
+in a group and a project, they are both triggered by an event in the
+project.
 
 Group webhooks can also be configured to listen for events that are
 specific to a group, including:
@@ -171,7 +173,8 @@ work you must have Ruby installed.
    ruby print_http_body.rb 8000
    ```
 
-1. In GitLab, add your webhook receiver as `http://my.host:8000/`.
+1. In GitLab, [configure the webhook](#configure-a-webhook-in-gitlab) and add your
+   receiver's URL, for example, `http://receiver.example.com:8000/`.
 
 1. Select **Test**. You should see something like this in the console:
 
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 6c79af972eb..b4fa1e8e8c1 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -224,7 +224,7 @@ This alternative ensures the compliance pipeline does not re-start the parent pi
 
 ## Configure project visibility, features, and permissions
 
-To configure project permissions:
+To configure visibility, features, and permissions for a project:
 
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > General**.
@@ -234,27 +234,6 @@ To configure project permissions:
 1. Use the [toggles](#project-feature-settings) to enable or disable features in the project.
 1. Select **Save changes**.
 
-When you disable a feature, the following additional features are disabled:
-
-- If you disable the **Issues** feature, project users cannot use:
-  - **Issue Boards**
-  - **Service Desk**
-  - Project users can still access **Milestones** from merge requests.
-
-- If you disable **Issues** and **Merge Requests**, project users cannot use:
-  - **Labels**
-  - **Milestones**
-
-- If you disable **Repository**, project users cannot access:
-  - **Merge requests**
-  - **CI/CD**
-  - **Container Registry**
-  - **Git Large File Storage**
-  - **Packages**
-
-- Metrics dashboard access requires reading project environments and deployments.
-  Users with access to the metrics dashboard can also access environments and deployments.
-
 ### Project feature settings
 
 Use the toggles to enable or disable features in the project.
@@ -278,6 +257,27 @@ Use the toggles to enable or disable features in the project.
 | **Operations**                   | ✓                         | Control access to Operations-related features, including [Operations Dashboard](../../../operations/index.md), [Environments and Deployments](../../../ci/environments/index.md), [Feature Flags](../../../operations/feature_flags.md). |
 | **Metrics Dashboard**            | ✓                         | Control access to [metrics dashboard](../integrations/prometheus.md). |
 
+When you disable a feature, the following additional features are also disabled:
+
+- If you disable the **Issues** feature, project users cannot use:
+  - **Issue Boards**
+  - **Service Desk**
+  - Project users can still access **Milestones** from merge requests.
+
+- If you disable **Issues** and **Merge Requests**, project users cannot use:
+  - **Labels**
+  - **Milestones**
+
+- If you disable **Repository**, project users cannot access:
+  - **Merge requests**
+  - **CI/CD**
+  - **Container Registry**
+  - **Git Large File Storage**
+  - **Packages**
+
+- Metrics dashboard access requires reading project environments and deployments.
+  Users with access to the metrics dashboard can also access environments and deployments.
+
 ## Disabling the CVE ID request button **(FREE SAAS)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/41203) in GitLab 13.4, only for public projects on GitLab.com.