Add latest changes from gitlab-org/gitlab@master

16 files changed, 42 insertions, 23 deletions

diff --git a/doc/.vale/gitlab/Substitutions.yml b/doc/.vale/gitlab/Substitutions.yml
index a0670d75f18..af426fa7e06 100644
--- a/doc/.vale/gitlab/Substitutions.yml
+++ b/doc/.vale/gitlab/Substitutions.yml
@@ -38,7 +38,7 @@ swap:
   to sign-in: to sign in
   can sign-in: can sign in
   x509: X.509
-  yaml: YAML
+  yml: YAML
   admin user: administrator
   admin users: administrators
   administrator permission: administrator access
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index a574ae6c9bc..7be1d4cafba 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -488,7 +488,7 @@ To configure the `s3` storage driver in Omnibus:
 
 **Installations from source**
 
-Configuring the storage driver is done in the registry configuration YML file created
+Configuring the storage driver is done in the registry configuration YAML file created
 when you [deployed your Docker registry](https://docs.docker.com/registry/deploying/).
 
 `s3` storage driver example:
@@ -611,7 +611,7 @@ However, this behavior is undesirable for registries used by internal hosts that
 
 **Installations from source**
 
-1. Add the `redirect` flag to your registry configuration YML file:
+1. Add the `redirect` flag to your registry configuration YAML file:
 
     ```yaml
     storage:
@@ -663,7 +663,7 @@ For Omnibus GitLab installations:
 
 For installations from source:
 
-1. Edit your registry configuration YML file:
+1. Edit your registry configuration YAML file:
 
     ```yaml
     storage:
@@ -856,7 +856,7 @@ To configure a notification endpoint in Omnibus:
 
 **Installations from source**
 
-Configuring the notification endpoint is done in your registry configuration YML file created
+Configuring the notification endpoint is done in your registry configuration YAML file created
 when you [deployed your Docker registry](https://docs.docker.com/registry/deploying/).
 
 Example:
@@ -1366,7 +1366,7 @@ You can add a configuration option for backwards compatibility.
 
 **For installations from source**
 
-1. Edit the YML configuration file you created when you [deployed the registry](https://docs.docker.com/registry/deploying/). Add the following snippet:
+1. Edit the YAML configuration file you created when you [deployed the registry](https://docs.docker.com/registry/deploying/). Add the following snippet:
 
    ```yaml
    compatibility:
@@ -1414,7 +1414,7 @@ and a simple solution would be to enable relative URLs in the Registry.
 
 **For installations from source**
 
-1. Edit the YML configuration file you created when you [deployed the registry](https://docs.docker.com/registry/deploying/). Add the following snippet:
+1. Edit the YAML configuration file you created when you [deployed the registry](https://docs.docker.com/registry/deploying/). Add the following snippet:
 
    ```yaml
    http:
diff --git a/doc/administration/redis/replication_and_failover_external.md b/doc/administration/redis/replication_and_failover_external.md
index 4f3e1278eac..998455e5621 100644
--- a/doc/administration/redis/replication_and_failover_external.md
+++ b/doc/administration/redis/replication_and_failover_external.md
@@ -218,7 +218,7 @@ The following steps should be performed in the GitLab application server
 which ideally should not have Redis or Sentinels in the same machine:
 
 1. Edit `/home/git/gitlab/config/resque.yml` following the example in
-   [resque.yml.example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/resque.yml.example), and uncomment the Sentinel lines, pointing to
+   [`resque.yml.example`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/resque.yml.example), and uncomment the Sentinel lines, pointing to
    the correct server credentials:
 
    ```yaml
diff --git a/doc/api/index.md b/doc/api/index.md
index 651e39d87c6..85530066fa6 100644
--- a/doc/api/index.md
+++ b/doc/api/index.md
@@ -390,6 +390,9 @@ In the following example, we list 50 [namespaces](namespaces.md) per page:
 curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/namespaces?per_page=50"
 ```
 
+NOTE:
+There is a [max offset allowed limit](../administration/instance_limits.md#max-offset-allowed-by-the-rest-api-for-offset-based-pagination) for offset pagination. You can change the limit in self-managed instances.
+
 #### Pagination `Link` header
 
 [`Link` headers](https://www.w3.org/wiki/LinkHeader) are returned with each
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 56e8b96d11f..3ebd38df8db 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -58,7 +58,7 @@ The process of configuring Review Apps is as follows:
 1. [Install](https://docs.gitlab.com/runner/install/) and [configure](https://docs.gitlab.com/runner/commands/) a runner to do deployment.
 1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI/CD variable](../variables/index.md) `${CI_COMMIT_REF_SLUG}`
    to create dynamic environments and restrict it to run only on branches.
-   Alternatively, you can get a YML template for this job by [enabling review apps](#enable-review-apps-button) for your project.
+   Alternatively, you can get a YAML template for this job by [enabling review apps](#enable-review-apps-button) for your project.
 1. Optionally, set a job that [manually stops](../environments/index.md#stop-an-environment) the Review Apps.
 
 ### Enable Review Apps button
diff --git a/doc/development/developing_with_solargraph.md b/doc/development/developing_with_solargraph.md
index 877fbad8ab2..d7e41187ace 100644
--- a/doc/development/developing_with_solargraph.md
+++ b/doc/development/developing_with_solargraph.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Gemfile packages [Solargraph](https://github.com/castwide/solargraph) language server for additional IntelliSense and code formatting capabilities with editors that support it.
 
-Example configuration for Solargraph can be found in [.solargraph.yml.example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.solargraph.yml.example) file. Copy the contents of this file to `.solargraph.yml` file for language server to pick this configuration up. Since `.solargraph.yml` configuration file is ignored by Git, it's possible to adjust configuration according to your needs.
+Example configuration for Solargraph can be found in [`.solargraph.yml.example`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.solargraph.yml.example) file. Copy the contents of this file to `.solargraph.yml` file for language server to pick this configuration up. Since `.solargraph.yml` configuration file is ignored by Git, it's possible to adjust configuration according to your needs.
 
 Refer to particular IDE plugin documentation on how to integrate it with Solargraph language server:
 
diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md
index 6d2b93b9462..e1e0da03abc 100644
--- a/doc/development/documentation/site_architecture/global_nav.md
+++ b/doc/development/documentation/site_architecture/global_nav.md
@@ -103,7 +103,7 @@ The global nav has five levels:
       - Doc
         - Doc
 
-You can view this structure in [the navigation.yml file](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/content/_data/navigation.yaml).
+You can view this structure in [the `navigation.yml` file](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/content/_data/navigation.yaml).
 
 **Do not** [add items](#add-a-navigation-entry) to the global nav without
 the consent of one of the technical writers.
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index b532826bcda..970a709027c 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -222,7 +222,7 @@ create an issue or an MR to propose a change to the user interface text.
 If the term is not in the word list, ask a GitLab Technical Writer for advice.
 
 Do not match the capitalization of terms or phrases on the [Features page](https://about.gitlab.com/features/)
-or [features.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml)
+or [`features.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml)
 by default.
 
 #### Other terms
diff --git a/doc/development/experiment_guide/experiment_rollout.md b/doc/development/experiment_guide/experiment_rollout.md
index afa32d75221..8df970659c6 100644
--- a/doc/development/experiment_guide/experiment_rollout.md
+++ b/doc/development/experiment_guide/experiment_rollout.md
@@ -29,7 +29,7 @@ This can be done via ChatOps:
 
 - [disable](../feature_flags/controls.md#disabling-feature-flags): `/chatops run feature set gitlab_experiment false`
 - [enable](../feature_flags/controls.md#process): `/chatops run feature delete gitlab_experiment`
-- This allows the `default_enabled` [value of true in the yml](https://gitlab.com/gitlab-org/gitlab/-/blob/016430f6751b0c34abb24f74608c80a1a8268f20/config/feature_flags/ops/gitlab_experiment.yml#L8) to be honored.
+- This allows the `default_enabled` [value of true in the YAML](https://gitlab.com/gitlab-org/gitlab/-/blob/016430f6751b0c34abb24f74608c80a1a8268f20/config/feature_flags/ops/gitlab_experiment.yml#L8) to be honored.
 
 ## Notes on feature flags
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index f94f044e75d..c1e6811732d 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -276,7 +276,7 @@ To disable a feature flag that has been enabled for a specific project you can r
 
 You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](index.md#selectively-disable-by-actor) the feature flags.
 
-If a feature flag is disabled via ChatOps, that will take precedence over the `default_enabled` value in the YML. In other words, you could have a feature enabled for on-premise installations but not for GitLab.com.
+If a feature flag is disabled via ChatOps, that will take precedence over the `default_enabled` value in the YAML. In other words, you could have a feature enabled for on-premise installations but not for GitLab.com.
 
 ### Feature flag change logging
 
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index a5661a77da3..382f9c20331 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -88,7 +88,7 @@ of the "GitLab" project on the Engineering Projects
 page in the handbook.
 
 To add yourself to this list, add the following to your profile in the
-[team.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml)
+[`team.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml)
 file and ask your manager to review and merge.
 
 ```yaml
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md
index b4ec9e8ccd3..0828ceed825 100644
--- a/doc/development/testing_guide/end_to_end/feature_flags.md
+++ b/doc/development/testing_guide/end_to_end/feature_flags.md
@@ -192,10 +192,26 @@ End-to-end tests should pass with a feature flag enabled before it is enabled on
 
 ### Automatic test execution when a feature flag definition changes
 
-If a merge request adds or edits a [feature flag definition file](../../feature_flags/index.md#feature-flag-definition-and-validation),
-two `package-and-qa` jobs will be included automatically in the merge request pipeline. One job will enable the defined
-feature flag and the other will disable it. The jobs execute the same suite of tests to confirm that they pass with if
-the feature flag is either enabled or disabled.
+There are two ways to confirm that end-to-end tests pass:
+
+- If a merge request adds or edits a [feature flag definition file](../../feature_flags/index.md#feature-flag-definition-and-validation),
+  two `package-and-qa` jobs (`package-and-qa-ff-enabled` and `package-and-qa-ff-disabled`) are included automatically in the merge request
+  pipeline. One job enables the defined feature flag and the other job disables it. The jobs execute the same suite of tests to confirm
+  that they pass with the feature flag either enabled or disabled.
+- In some cases, if `package-and-qa` hasn't been triggered automatically, or if it has run the tests with the default feature flag values
+  (which might not be desired), you can create a Draft MR that enables the feature flag to ensure that all E2E tests pass with the feature
+  flag enabled.
+
+### Troubleshooting end-to-end test failures with feature flag enabled
+
+If enabling the feature flag results in E2E test failures, you can browse the artifacts in the failed pipeline to see screenshots of the failed tests. After which, you can either:
+
+- Identify tests that need to be updated and contact the relevant [counterpart Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) responsible for updating the tests or assisting another engineer to do so. However, if a change does not go through [quad-planning](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning/) and a required test update is not made, test failures could block deployment. 
+- Run the failed tests [locally](https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa#run-the-end-to-end-tests-in-a-local-development-environment)
+  with the [feature flag enabled](https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa#running-tests-with-a-feature-flag-enabled-or-disabled).
+  This option requires considerable amount of setup, but you'll be able to see what the browser is doing as it's running the failed
+  tests, which can help debug the problem faster. You can also refer to the [Troubleshooting Guide for E2E tests](troubleshooting.md) for
+  support for common blockers.  
 
 ### Test execution during feature development
 
diff --git a/doc/install/installation.md b/doc/install/installation.md
index ac3360f3d4f..d59c71c24d4 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -859,7 +859,7 @@ You can set the Administrator/root password and email by supplying them in envir
 sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production GITLAB_ROOT_PASSWORD=yourpassword GITLAB_ROOT_EMAIL=youremail GITLAB_LICENSE_FILE="/path/to/license"
 ```
 
-### Secure secrets.yml
+### Secure `secrets.yml`
 
 The `secrets.yml` file stores encryption keys for sessions and secure variables.
 Backup `secrets.yml` someplace safe, but don't store it in the same place as your database backups.
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 3f80f52c97a..c41385a3569 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -450,7 +450,7 @@ To allowlist specific vulnerabilities, follow these steps:
    the format described in [`vulnerability-allowlist.yml` data format](#vulnerability-allowlistyml-data-format).
 1. Add the `vulnerability-allowlist.yml` file to the root folder of your project's Git repository.
 
-#### vulnerability-allowlist.yml data format
+#### `vulnerability-allowlist.yml` data format
 
 The `vulnerability-allowlist.yml` file is a YAML file that specifies a list of CVE IDs of vulnerabilities that are **allowed** to exist, because they're _false positives_, or they're _not applicable_.
 
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 611a68d2660..a8e1c7ec369 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -574,7 +574,7 @@ DAST scan with both configured exits with an error.
 
 By default, several rules are disabled because they either take a long time to
 run or frequently generate false positives. The complete list of disabled rules
-can be found in [exclude_rules.yml](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/src/config/exclude_rules.yml).
+can be found in [`exclude_rules.yml`](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/src/config/exclude_rules.yml).
 
 The lists for `DAST_EXCLUDE_RULES` and `DAST_ONLY_INCLUDE_RULES` **must** be enclosed in double
 quotes (`"`), otherwise they are interpreted as numeric values.
diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md
index 6e751b907eb..4c8e648537c 100644
--- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md
+++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md
@@ -38,7 +38,7 @@ Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annot
 - `prometheus.io/scrape: "true"`
 - `prometheus.io/port: "10254"`
 
-Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible to edit the NGINX Ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
+Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible to edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
 
 ## Specifying the Environment label