Add latest changes from gitlab-org/gitlab@master

6 files changed, 28 insertions, 20 deletions

diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md
index fe4d991689a..56af5f56cfa 100644
--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -21,9 +21,8 @@ GitLab has several features based on receiving incoming emails:
 
 ## Requirements
 
-It is **not** recommended to use an email address that receives any
-messages not intended for the GitLab instance. Any incoming emails not intended
-for GitLab receive a reject notice.
+We recommend using an email address that receives **only** messages that are intended for
+the GitLab instance. Any incoming emails not intended for GitLab receive a reject notice.
 
 Handling incoming emails requires an [IMAP](https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol)-enabled
 email account. GitLab requires one of the following three strategies:
@@ -131,6 +130,9 @@ list.
 
    ```shell
    sudo gitlab-ctl reconfigure
+
+   # Needed when enabling or disabling for the first time but not for password changes.
+   # See https://gitlab.com/gitlab-org/gitlab-foss/-/issues/23560#note_61966788
    sudo gitlab-ctl restart
    ```
 
diff --git a/doc/administration/redis/replication_and_failover_external.md b/doc/administration/redis/replication_and_failover_external.md
index 2716d9bba37..1d60e027157 100644
--- a/doc/administration/redis/replication_and_failover_external.md
+++ b/doc/administration/redis/replication_and_failover_external.md
@@ -21,7 +21,7 @@ The following are the requirements for providing your own Redis instance:
   [requirements page](../../install/requirements.md).
 - Standalone Redis or Redis high availability with Sentinel are supported. Redis
   Cluster is not supported.
-- Managed Redis from cloud providers such as AWS ElastiCache will work. If these
+- Managed Redis from cloud providers such as AWS ElastiCache works fine. If these
   services support high availability, be sure it is **not** the Redis Cluster type.
 
 Note the Redis node's IP address or hostname, port, and password (if required).
@@ -53,7 +53,7 @@ Note the Redis node's IP address or hostname, port, and password (if required).
 This is the documentation for configuring a scalable Redis setup when
 you have installed Redis all by yourself and not using the bundled one that
 comes with the Omnibus packages, although using the Omnibus GitLab packages is
-highly recommend as we optimize them specifically for GitLab, and we will take
+highly recommend as we optimize them specifically for GitLab, and we take
 care of upgrading Redis to the latest supported version.
 
 Note also that you may elect to override all references to
@@ -76,7 +76,7 @@ requirements:
   (e.g., one from an internal network).
 - Since Redis 3.2, you must define a password to receive external connections
   (`requirepass`).
-- If you are using Redis with Sentinel, you will also need to define the same
+- If you are using Redis with Sentinel, you also need to define the same
   password for the replica password definition (`masterauth`) in the same instance.
 
 In addition, read the prerequisites as described in the
@@ -176,7 +176,7 @@ primary with IP `10.0.0.1` (some settings might overlap with the primary):
    sentinel monitor gitlab-redis 10.0.0.1 6379 2
 
    ## Define with `sentinel down-after-milliseconds` the time in `ms`
-   ## that an unresponsive server will be considered down.
+   ## that an unresponsive server is considered down.
    sentinel down-after-milliseconds gitlab-redis 10000
 
    ## Define a value for `sentinel failover_timeout` in `ms`. This has multiple
@@ -197,7 +197,7 @@ primary with IP `10.0.0.1` (some settings might overlap with the primary):
    ##
    ## * The maximum time a failover in progress waits for all the replicas to be
    ##   reconfigured as replicas of the new primary. However even after this time
-   ##   the replicas will be reconfigured by the Sentinels anyway, but not with
+   ##   the replicas are reconfigured by the Sentinels anyway, but not with
    ##   the exact parallel-syncs progression as specified.
    sentinel failover_timeout 30000
    ```
@@ -249,7 +249,7 @@ In a real world usage, you would also set up firewall rules to prevent
 unauthorized access from other machines, and block traffic from the
 outside ([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png)).
 
-For this example, **Sentinel 1** will be configured in the same machine as the
+For this example, **Sentinel 1** is configured in the same machine as the
 **Redis Primary**, **Sentinel 2** and **Sentinel 3** in the same machines as the
 **Replica 1** and **Replica 2** respectively.
 
@@ -261,11 +261,11 @@ Here is a list and description of each **machine** and the assigned **IP**:
 - `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
-by the Sentinel nodes, the Redis nodes will be reconfigured and the **Primary**
-will change permanently (including in `redis.conf`) from one node to the other,
+by the Sentinel nodes, the Redis nodes are reconfigured and the **Primary**
+changes permanently (including in `redis.conf`) from one node to the other,
 until a new failover is initiated again.
 
-The same thing will happen with `sentinel.conf` that will be overridden after the
+The same thing happens with `sentinel.conf` that is overridden after the
 initial execution, after any new sentinel node starts watching the **Primary**,
 or a failover promotes a different **Primary** node.
 
diff --git a/doc/development/experiment_guide/experimentation.md b/doc/development/experiment_guide/experimentation.md
index 7135f8acd9b..d631630b77e 100644
--- a/doc/development/experiment_guide/experimentation.md
+++ b/doc/development/experiment_guide/experimentation.md
@@ -6,6 +6,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Create an A/B test with `Experimentation Module`
 
+NOTE:
+We recommend using [GLEX](gitlab_experiment.md) for new experiments.
+
 ## Implement the experiment
 
 1. Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in
diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md
index e39ef48517f..2cfb9517a60 100644
--- a/doc/development/experiment_guide/index.md
+++ b/doc/development/experiment_guide/index.md
@@ -46,16 +46,10 @@ One is built into GitLab directly and has been around for a while (this is calle
 to as `Gitlab::Experiment` -- GLEX for short.
 
 Both approaches use [experiment](../feature_flags/index.md#experiment-type)
-feature flags, and there is currently no strong suggestion to use one over the other.
+feature flags. We recommend using GLEX rather than `Experimentation Module` for new experiments.
 
-| Feature              | `Experimentation Module` | GLEX |
-| -------------------- |------------------------- | ---- |
-| Record user grouping | Yes                      | No   |
-| Uses feature flags   | Yes                      | Yes  |
-| Multivariate (A/B/n) | No                       | Yes  |
-
-- [Implementing an A/B experiment using `Experimentation Module`](experimentation.md)
 - [Implementing an A/B/n experiment using GLEX](gitlab_experiment.md)
+- [Implementing an A/B experiment using `Experimentation Module`](experimentation.md)
 
 Historical Context: `Experimentation Module` was built iteratively with the needs that
 appeared while implementing Growth sub-department experiments, while GLEX was built
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 49c511c2b85..f47a5164d43 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -105,6 +105,12 @@ Default client accepts two parameters: `resolvers` and `config`.
   - `baseUrl` allows us to pass a URL for GraphQL endpoint different from our main endpoint (for example, `${gon.relative_url_root}/api/graphql`)
   - `assumeImmutableResults` (set to `false` by default) - this setting, when set to `true`, assumes that every single operation on updating Apollo Cache is immutable. It also sets `freezeResults` to `true`, so any attempt on mutating Apollo Cache throws a console warning in development environment. Please ensure you're following the immutability pattern on cache update operations before setting this option to `true`.
   - `fetchPolicy` determines how you want your component to interact with the Apollo cache. Defaults to "cache-first".
+    
+### Multiple client queries for the same object
+
+If you are make multiple queries to the same Apollo client object you might encounter the following error: "Store error: the application attempted to write an object with no provided ID but the store already contains an ID of SomeEntity". [This error only should occur when you have made a query with an ID field for a portion, then made another that returns what would be the same object, but is missing the ID field.](https://github.com/apollographql/apollo-client/issues/2510#issue-271829009)
+
+Please note this is being tracked in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/326101) and the documentation will be updated when this issue is resolved. 
 
 ## GraphQL Queries
 
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index c4194be23a4..4fd0003795d 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -132,6 +132,9 @@ the QA smoke suite.
 
 You can also manually start the `review-qa-all`: it runs the full QA suite.
 
+After the end-to-end test runs have finished, [Allure reports](https://github.com/allure-framework/allure2) are generated and published by
+the `allure-report-qa-smoke` and `allure-report-qa-all` jobs. A comment with links to the reports are added to the merge request.
+
 ## Performance Metrics
 
 On every [pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/125315730) in the `qa` stage, the