Add latest changes from gitlab-org/gitlab@master

9 files changed, 83 insertions, 14 deletions

diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 26acab510cf..8bb060b3a08 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -87,7 +87,7 @@ GitLab does not require a special file system and can work with:
 
 Geo triggers garbage collection in Gitaly to [deduplicate forked repositories](../../../development/git_object_deduplication.md#git-object-deduplication-and-gitlab-geo) on Geo secondary sites.
 
-Communication is done via Gitaly's own gRPC API, with three possible ways of synchronization:
+The Gitaly gRPC API does the communication, with three possible ways of synchronization:
 
 - Using regular Git clone/fetch from one Geo site to another (with special authentication).
 - Using repository snapshots (for when the first method fails or repository is corrupt).
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index 51d6e9ae1fd..81a96ca698c 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -223,7 +223,7 @@ from the Linux package and is no longer supported.
 
 Puma has a multi-thread architecture that uses less memory than a multi-process
 application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory
-consumption. Most Rails application requests normally include a proportion of I/O wait time.
+consumption. Most Rails application requests usually include a proportion of I/O wait time.
 
 During I/O wait time, MRI Ruby releases the GVL to other threads.
 Multi-threaded Puma can therefore still serve more requests than a single process.
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index 514a0b255c5..46683053510 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -330,7 +330,7 @@ Note the following:
 
 NOTE:
 For Windows runners, using `echo` to write to `.env` files may fail. Using the PowerShell `Add-Content`command
-will help in such cases. For example:
+helps in such cases. For example:
 
 ```powershell
 Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"
@@ -534,7 +534,7 @@ In this example, if the configuration is not identical:
 
 Also in the example, `GIT_STRATEGY` is set to `none`. If the
 `stop_review_app` job is [automatically triggered](../environments/index.md#stop-an-environment),
-the runner won't try to check out the code after the branch is deleted.
+the runner doesn't try to check out the code after the branch is deleted.
 
 The `stop_review_app` job **must** have the following keywords defined:
 
@@ -975,7 +975,7 @@ the `review/feature-1` spec takes precedence over `review/*` and `*` specs.
 
 ### Rename an environment
 
-> Renaming environments through the UI was [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68550) in GitLab 14.3. Renaming environments through the API was deprecated and [will be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/338897) in GitLab 15.0.
+> Renaming environments through the UI was [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68550) in GitLab 14.3. Renaming environments through the API was deprecated and [is planned to be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/338897) in GitLab 15.0.
 
 Renaming an environment through the UI is not possible.
 Instead, you need to delete the old environment and create a new one:
@@ -1124,7 +1124,7 @@ To fix this, use one of the following solutions:
 Starting from GitLab 14.5, GitLab [deletes old deployment refs](#archive-old-deployments)
 to keep your Git repository performant.
 
-If you have to restore archived Git-refs, please ask an administrator of your self-managed GitLab instance
+If you have to restore archived Git-refs, ask an administrator of your self-managed GitLab instance
 to execute the following command on Rails console:
 
 ```ruby
diff --git a/doc/ci/examples/semantic-release.md b/doc/ci/examples/semantic-release.md
index 1fa526e787a..8ae4cf61e37 100644
--- a/doc/ci/examples/semantic-release.md
+++ b/doc/ci/examples/semantic-release.md
@@ -35,7 +35,7 @@ You can also view or fork the complete [example source](https://gitlab.com/gitla
    }
    ```
 
-1. Update the `files` key with glob patterns that selects all files that should be included in the published module. More information about `files` can be found [in npm's documentation](https://docs.npmjs.com/cli/v6/configuring-npm/package-json/#files).
+1. Update the `files` key with glob patterns that selects all files that should be included in the published module. More information about `files` can be found [in the npm documentation](https://docs.npmjs.com/cli/v6/configuring-npm/package-json/#files).
 
 1. Add a `.gitignore` file to the project to avoid committing `node_modules`:
 
diff --git a/doc/ci/services/index.md b/doc/ci/services/index.md
index bbd2f822481..c33288772aa 100644
--- a/doc/ci/services/index.md
+++ b/doc/ci/services/index.md
@@ -9,7 +9,7 @@ type: index
 # Services **(FREE)**
 
 When you configure CI/CD, you specify an image, which is used to create the container
-where your jobs will run. To specify this image, you use the `image` keyword.
+where your jobs run. To specify this image, you use the `image` keyword.
 
 You can specify an additional image by using the `services` keyword. This additional
 image is used to create another container, which is available to the first container.
@@ -343,7 +343,7 @@ services:
     command: ["/usr/bin/super-sql", "run"]
 ```
 
-The syntax of `command` is similar to [Dockerfile's `CMD`](https://docs.docker.com/engine/reference/builder/#cmd).
+The syntax of `command` is similar to [Dockerfile `CMD`](https://docs.docker.com/engine/reference/builder/#cmd).
 
 ## Using `services` with `docker run` (Docker-in-Docker) side-by-side
 
@@ -417,10 +417,10 @@ Accepted values are:
 - Enabled: `TRUE`, `true`, `True`
 - Disabled: `FALSE`, `false`, `False`
 
-Any other values will result in an error message and effectively disable the feature.
+Any other values result in an error message and effectively disable the feature.
 
-When enabled, logs for _all_ service containers will be captured and streamed into the jobs trace log concurrently with
-other logs. Logs from each container will be prefixed with the container's aliases, and displayed in a different color.
+When enabled, logs for _all_ service containers are captured and streamed into the jobs trace log concurrently with
+other logs. Logs from each container are prefixed with the container's aliases, and displayed in a different color.
 
 NOTE:
 You may want to adjust the logging level in the service container for which you want to capture logs since the default
diff --git a/doc/ci/testing/test_coverage_visualization.md b/doc/ci/testing/test_coverage_visualization.md
index 9bff8dbf780..e2a1a4a2c5e 100644
--- a/doc/ci/testing/test_coverage_visualization.md
+++ b/doc/ci/testing/test_coverage_visualization.md
@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 With the help of [GitLab CI/CD](../index.md), you can collect the test
 coverage information of your favorite testing or coverage-analysis tool, and visualize
-this information inside the file diff view of your merge requests (MRs). This will allow you
+this information inside the file diff view of your merge requests (MRs). This allows you
 to see which lines are covered by tests, and which lines still require coverage, before the
 MR is merged.
 
@@ -64,7 +64,7 @@ You must configure these separately.
 A limit of 100 `<source>` nodes for Cobertura format XML files applies. If your Cobertura report exceeds
 100 nodes, there can be mismatches or no matches in the merge request diff view.
 
-A single Cobertura XML file can be no more than 10MiB. For large projects, split the Cobertura XML into
+A single Cobertura XML file can be no more than 10 MiB. For large projects, split the Cobertura XML into
 smaller files. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328772) for more details.
 When submitting many files, it can take a few minutes for coverage to show on a merge request.
 
diff --git a/doc/development/database/query_recorder.md b/doc/development/database/query_recorder.md
index dfaaf8afcde..bae211c1618 100644
--- a/doc/development/database/query_recorder.md
+++ b/doc/development/database/query_recorder.md
@@ -148,3 +148,4 @@ There are multiple ways to find the source of queries.
 - [Performance guidelines](../performance.md)
 - [Merge request performance guidelines - Query counts](../merge_request_concepts/performance.md#query-counts)
 - [Merge request performance guidelines - Cached queries](../merge_request_concepts/performance.md#cached-queries)
+- [RedisCommands::Recorder](../redis.md#n1-calls-problem) For testing `N+1` calls in Redis
diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md
index e7922b54e02..a98ba3e4ee8 100644
--- a/doc/development/documentation/workflow.md
+++ b/doc/development/documentation/workflow.md
@@ -15,6 +15,21 @@ Anyone can contribute to the GitLab documentation! You can create a merge reques
 If you are working on a feature or enhancement, use the
 [feature workflow process described in the GitLab Handbook](https://about.gitlab.com/handbook/product/ux/technical-writing/workflow/#documentation-for-a-product-change).
 
+## Do not use ChatGPT or AI-generated content for the docs
+
+GitLab documentation is distributed under the [CC BY-SA 4.0 license](https://creativecommons.org/licenses/by-sa/4.0/), which presupposes that GitLab owns the documentation.
+
+Under current law in the US and the EU, it’s possible that AI-generated works might either:
+
+- not be owned by anyone because they weren't created by a human, or
+- belong to the AI training data’s creator, if the AI verbatim reproduces content that it trained on 
+
+If the documentation contains AI-generated content, GitLab probably wouldn't own this content, which would risk invalidating the CC BY-SA 4.0 license.
+
+Contributions to GitLab documentation are made under either our [DCO or our CLA terms](https://about.gitlab.com/community/contribute/dco-cla/). In both, contributors have to make certain certifications about the authorship of their work that they can't validly make for AI-generated text.
+
+For these reasons, do not add AI-generated content to the documentation.
+
 ## How to update the docs
 
 If you are not a GitLab team member, or do not have the Developer role for the GitLab repository, to update GitLab documentation:
diff --git a/doc/development/redis.md b/doc/development/redis.md
index 75c7df0737b..45712b14c0a 100644
--- a/doc/development/redis.md
+++ b/doc/development/redis.md
@@ -142,6 +142,59 @@ those that use the most memory.
 Currently this is not run automatically for the GitLab.com Redis instances, but
 is run manually on an as-needed basis.
 
+## N+1 calls problem
+
+> Introduced in [`spec/support/helpers/redis_commands/recorder.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/helpers/redis_commands/recorder.rb) via [`f696f670`](https://gitlab.com/gitlab-org/gitlab/-/commit/f696f670005435472354a3dc0c01aa271aef9e32)
+
+`RedisCommands::Recorder` is a tool for detecting Redis N+1 calls problem from tests.
+
+Redis is often used for caching purposes. Usually, cache calls are lightweight and
+cannot generate enough load to affect the Redis instance. However, it is still
+possible to trigger expensive cache recalculations without knowing that. Use this
+tool to analyze Redis calls, and define expected limits for them.
+
+### Create a test
+
+It is implemented as a [`ActiveSupport::Notifications`](https://api.rubyonrails.org/classes/ActiveSupport/Notifications.html) instrumenter.
+
+You can create a test that verifies that a testable code only makes
+a single Redis call:
+
+```ruby
+it 'avoids N+1 Redis calls' do
+  control = RedisCommands::Recorder.new { visit_page }
+
+  expect(control.count).to eq(1)
+end
+```
+
+or a test that verifies the number of specific Redis calls:
+
+```ruby
+it 'avoids N+1 sadd Redis calls' do
+  control = RedisCommands::Recorder.new { visit_page }
+
+  expect(control.by_command(:sadd).count).to eq(1)
+end
+```
+
+You can also provide a pattern to capture only specific Redis calls:
+
+```ruby
+it 'avoids N+1 Redis calls to forks_count key' do
+  control = RedisCommands::Recorder.new(pattern: 'forks_count') { visit_page }
+
+  expect(control.count).to eq(1)
+end
+```
+
+These tests can help to identify N+1 problems related to Redis calls,
+and make sure that the fix for them works as expected.
+
+### See also
+
+- [Database query recorder](database/query_recorder.md)
+
 ## Utility classes
 
 We have some extra classes to help with specific use cases. These are