Add latest changes from gitlab-org/gitlab@master

8 files changed, 83 insertions, 61 deletions

diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index 544985d7edc..02086ec5f1b 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -147,7 +147,7 @@ Best practices for [client-side logging](logging.md) for GitLab frontend develop
 
 ## [Internationalization (i18n) and Translations](../i18n/externalization.md)
 
-Frontend internationalization support is described in [this document](../i18n/).
+Frontend internationalization support is described in [this document](../i18n/index.md).
 The [externalization part of the guide](../i18n/externalization.md) explains the helpers/methods available.
 
 ## [Troubleshooting](troubleshooting.md)
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index a8dc16f2895..d7589681ce6 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -426,6 +426,21 @@ Feature.enabled?(:a_feature, project) && Feature.disabled?(:a_feature_override,
 /chatops run feature set --project=gitlab-org/gitlab a_feature_override true
 ```
 
+#### Percentage-based actor selection
+
+When using the percentage rollout of actors on multiple feature flags, the actors for each feature flag are selected separately.
+
+For example, the following feature flags are enabled for a certain percentage of actors:
+
+```plaintext
+/chatops run chatops feature set feature-set-1 25 --actors
+/chatops run chatops feature set feature-set-2 25 --actors
+```
+
+If a project A has `:feature-set-1` enabled, there is no guarantee that project A also has `:feature-set-2` enabled.
+
+For more detail, see [This is how percentages work in Flipper](https://www.hackwithpassion.com/this-is-how-percentages-work-in-flipper).
+
 #### Use actors for verifying in production
 
 WARNING:
diff --git a/doc/development/features_inside_dot_gitlab.md b/doc/development/features_inside_dot_gitlab.md
index ca7dbd6adde..f30a041931e 100644
--- a/doc/development/features_inside_dot_gitlab.md
+++ b/doc/development/features_inside_dot_gitlab.md
@@ -14,8 +14,8 @@ When implementing new features, please refer to these existing features to avoid
 - [Merge request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.
 - [GitLab agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
 - [CODEOWNERS](../user/project/code_owners.md#set-up-code-owners): `.gitlab/CODEOWNERS`.
-- [Route Maps](../ci/review_apps/#route-maps): `.gitlab/route-map.yml`.
+- [Route Maps](../ci/review_apps/index.md#route-maps): `.gitlab/route-map.yml`.
 - [Customize Auto DevOps Helm Values](../topics/autodevops/customize.md#customize-values-for-helm-chart): `.gitlab/auto-deploy-values.yaml`.
 - [Insights](../user/project/insights/index.md#configure-your-insights): `.gitlab/insights.yml`.
 - [Service Desk Templates](../user/project/service_desk.md#using-customized-email-templates): `.gitlab/service_desk_templates/`.
-- [Web IDE](../user/project/web_ide/#web-ide-configuration-file): `.gitlab/.gitlab-webide.yml`.
+- [Web IDE](../user/project/web_ide/index.md#web-ide-configuration-file): `.gitlab/.gitlab-webide.yml`.
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index a02fc018969..55e57a3c2ee 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -314,7 +314,7 @@ This documentation gives an overview of the report JSON format,
 as well as recommendations and examples to help integrators set its fields.
 The format is extensively described in the documentation of
 [SAST](../../user/application_security/sast/index.md#reports-json-format),
-[DAST](../../user/application_security/dast/#reports),
+[DAST](../../user/application_security/dast/index.md#reports),
 [Dependency Scanning](../../user/application_security/dependency_scanning/index.md#reports-json-format),
 and [Container Scanning](../../user/application_security/container_scanning/index.md#reports-json-format)
 
diff --git a/doc/development/redis/new_redis_instance.md b/doc/development/redis/new_redis_instance.md
index 8731cc469ce..efaf1e5a6d0 100644
--- a/doc/development/redis/new_redis_instance.md
+++ b/doc/development/redis/new_redis_instance.md
@@ -169,7 +169,7 @@ MultiStore uses two feature flags to control the actual migration:
 - `use_primary_and_secondary_stores_for_[store_name]`
 - `use_primary_store_as_default_for_[store_name]`
 
-For example, if our new Redis instance is called `Gitlab::Redis::Foo`, we can [create](../../../ee/development/feature_flags/#create-a-new-feature-flag) two feature flags by executing:
+For example, if our new Redis instance is called `Gitlab::Redis::Foo`, we can [create](../feature_flags/index.md#create-a-new-feature-flag) two feature flags by executing:
 
 ```shell
 bin/feature-flag use_primary_and_secondary_stores_for_foo
diff --git a/doc/development/sidekiq/compatibility_across_updates.md b/doc/development/sidekiq/compatibility_across_updates.md
index a9897929596..1d369b5a970 100644
--- a/doc/development/sidekiq/compatibility_across_updates.md
+++ b/doc/development/sidekiq/compatibility_across_updates.md
@@ -28,7 +28,7 @@ others - particularly [latency-sensitive jobs](worker_attributes.md#latency-sens
 this will result in a poor user experience.
 
 This only applies to new worker classes when they are first introduced.
-As we recommend [using feature flags](../feature_flags/) as a general
+As we recommend [using feature flags](../feature_flags/index.md) as a general
 development process, it's best to control the entire change (including
 scheduling of the new Sidekiq worker) with a feature flag.
 
diff --git a/doc/development/testing_guide/contract/consumer_tests.md b/doc/development/testing_guide/contract/consumer_tests.md
index df7c9ee0abd..46f4f446ad9 100644
--- a/doc/development/testing_guide/contract/consumer_tests.md
+++ b/doc/development/testing_guide/contract/consumer_tests.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Writing consumer tests
 
-This tutorial guides you through writing a consumer test from scratch. To start, the consumer tests are written using [`jest-pact`](https://github.com/pact-foundation/jest-pact) that builds on top of [`pact-js`](https://github.com/pact-foundation/pact-js). This tutorial shows you how to write a consumer test for the `/discussions.json` endpoint, which is actually `/:namespace_name/:project_name/-/merge_requests/:id/discussions.json`.
+This tutorial guides you through writing a consumer test from scratch. To start, the consumer tests are written using [`jest-pact`](https://github.com/pact-foundation/jest-pact) that builds on top of [`pact-js`](https://github.com/pact-foundation/pact-js). This tutorial shows you how to write a consumer test for the `/discussions.json` REST API endpoint, which is actually `/:namespace_name/:project_name/-/merge_requests/:id/discussions.json`. For an example of a GraphQL consumer test, see [`spec/contracts/consumer/specs/project/pipeline/show.spec.js`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/spec/contracts/consumer/specs/project/pipeline/show.spec.js).
 
 ## Create the skeleton
 
@@ -24,7 +24,7 @@ To learn more about how the contract test directory is structured, see the contr
 The Pact consumer test is defined through the `pactWith` function that takes `PactOptions` and the `PactFn`.
 
 ```javascript
-const { pactWith } = require('jest-pact');
+import { pactWith } from 'jest-pact';
 
 pactWith(PactOptions, PactFn);
 ```
@@ -34,7 +34,7 @@ pactWith(PactOptions, PactFn);
 `PactOptions` with `jest-pact` introduces [additional options](https://github.com/pact-foundation/jest-pact/blob/dce370c1ab4b7cb5dff12c4b62246dc229c53d0e/README.md#defaults) that build on top of the ones [provided in `pact-js`](https://github.com/pact-foundation/pact-js#constructor). In most cases, you define the `consumer`, `provider`, `log`, and `dir` options for these tests.
 
 ```javascript
-const { pactWith } = require('jest-pact');
+import { pactWith } from 'jest-pact';
 
 pactWith(
   {
@@ -54,7 +54,7 @@ To learn more about how to name the consumers and providers, see contract testin
 The `PactFn` is where your tests are defined. This is where you set up the mock provider and where you can use the standard Jest methods like [`Jest.describe`](https://jestjs.io/docs/api#describename-fn), [`Jest.beforeEach`](https://jestjs.io/docs/api#beforeeachfn-timeout), and [`Jest.it`](https://jestjs.io/docs/api#testname-fn-timeout). For more information, see [https://jestjs.io/docs/api](https://jestjs.io/docs/api).
 
 ```javascript
-const { pactWith } = require('jest-pact');
+import { pactWith } from 'jest-pact';
 
 pactWith(
   {
@@ -70,7 +70,7 @@ pactWith(
 
       });
 
-      it('return a successful body', () => {
+      it('return a successful body', async () => {
 
       });
     });
@@ -92,8 +92,8 @@ For this tutorial, define four attributes for the `Interaction`:
 After you define the `Interaction`, add that interaction to the mock provider by calling `addInteraction`.
 
 ```javascript
-const { pactWith } = require('jest-pact');
-const { Matchers } = require('@pact-foundation/pact');
+import { pactWith } from 'jest-pact';
+import { Matchers } from '@pact-foundation/pact';
 
 pactWith(
   {
@@ -132,7 +132,7 @@ pactWith(
         provider.addInteraction(interaction);
       });
 
-      it('return a successful body', () => {
+      it('return a successful body', async () => {
 
       });
     });
@@ -142,38 +142,36 @@ pactWith(
 
 ### Response body `Matchers`
 
-Notice how we use `Matchers` in the `body` of the expected response. This allows us to be flexible enough to accept different values but still be strict enough to distinguish between valid and invalid values. We must ensure that we have a tight definition that is neither too strict nor too lax. Read more about the [different types of `Matchers`](https://github.com/pact-foundation/pact-js#using-the-v3-matching-rules).
+Notice how we use `Matchers` in the `body` of the expected response. This allows us to be flexible enough to accept different values but still be strict enough to distinguish between valid and invalid values. We must ensure that we have a tight definition that is neither too strict nor too lax. Read more about the [different types of `Matchers`](https://github.com/pact-foundation/pact-js/blob/master/docs/matching.md). We are currently using the V2 matching rules.
 
 ## Write the test
 
 After the mock provider is set up, you can write the test. For this test, you make a request and expect a particular response.
 
-First, set up the client that makes the API request. To do that, create `spec/contracts/consumer/endpoints/project/merge_requests.js` and add the following API request.
+First, set up the client that makes the API request. To do that, create `spec/contracts/consumer/resources/api/project/merge_requests.js` and add the following API request. If the endpoint is a GraphQL, then we create it under `spec/contracts/consumer/resources/graphql` instead.
 
 ```javascript
-const axios = require('axios');
-
-exports.getDiscussions = (endpoint) => {
-  const url = endpoint.url;
-
-  return axios
-    .request({
-      method: 'GET',
-      baseURL: url,
-      url: '/gitlab-org/gitlab-qa/-/merge_requests/1/discussions.json',
-      headers: { Accept: '*/*' },
-    })
-    .then((response) => response.data);
-};
+import axios from 'axios';
+
+export async function getDiscussions(endpoint) {
+  const { url } = endpoint;
+
+  return axios({
+    method: 'GET',
+    baseURL: url,
+    url: '/gitlab-org/gitlab-qa/-/merge_requests/1/discussions.json',
+    headers: { Accept: '*/*' },
+  })
+}
 ```
 
 After that's set up, import it to the test file and call it to make the request. Then, you can make the request and define your expectations.
 
 ```javascript
-const { pactWith } = require('jest-pact');
-const { Matchers } = require('@pact-foundation/pact');
+import { pactWith } from 'jest-pact';
+import { Matchers } from '@pact-foundation/pact';
 
-const { getDiscussions } = require('../endpoints/project/merge_requests');
+import { getDiscussions } from '../../../resources/api/project/merge_requests';
 
 pactWith(
   {
@@ -211,17 +209,17 @@ pactWith(
         };
       });
 
-      it('return a successful body', () => {
-        return getDiscussions({
+      it('return a successful body', async () => {
+        const discussions = await getDiscussions({
           url: provider.mockService.baseUrl,
-        }).then((discussions) => {
-          expect(discussions).toEqual(Matchers.eachLike({
-            id: 'fd73763cbcbf7b29eb8765d969a38f7d735e222a',
-            project_id: 6954442,
-            ...
-            resolved: true
-          }));
         });
+        
+        expect(discussions).toEqual(Matchers.eachLike({
+          id: 'fd73763cbcbf7b29eb8765d969a38f7d735e222a',
+          project_id: 6954442,
+          ...
+          resolved: true
+        }));
       });
     });
   },
@@ -237,7 +235,7 @@ As you may have noticed, the request and response definitions can get large. Thi
 Create a file under `spec/contracts/consumer/fixtures/project/merge_request` called `discussions.fixture.js` where you will place the `request` and `response` definitions.
 
 ```javascript
-const { Matchers } = require('@pact-foundation/pact');
+import { Matchers } from '@pact-foundation/pact';
 
 const body = Matchers.eachLike({
   id: Matchers.string('fd73763cbcbf7b29eb8765d969a38f7d735e222a'),
@@ -254,11 +252,15 @@ const Discussions = {
     headers: {
       'Content-Type': 'application/json; charset=utf-8',
     },
-    body: body,
+    body,
   },
 
-  request: {
+  scenario: {
+    state: 'a merge request with discussions exists',
     uponReceiving: 'a request for discussions',
+  },
+
+  request: {
     withRequest: {
       method: 'GET',
       path: '/gitlab-org/gitlab-qa/-/merge_requests/1/discussions.json',
@@ -275,36 +277,41 @@ exports.Discussions = Discussions;
 With all of that moved to the `fixture`, you can simplify the test to the following:
 
 ```javascript
-const { pactWith } = require('jest-pact');
+import { pactWith } from 'jest-pact';
+
+import { Discussions } from '../../../fixtures/project/merge_request/discussions.fixture';
+import { getDiscussions } from '../../../resources/api/project/merge_requests';
 
-const { Discussions } = require('../fixtures/discussions.fixture');
-const { getDiscussions } = require('../endpoints/project/merge_requests');
+const CONSUMER_NAME = 'MergeRequest#show';
+const PROVIDER_NAME = 'Merge Request Discussions Endpoint';
+const CONSUMER_LOG = '../logs/consumer.log';
+const CONTRACT_DIR = '../contracts/project/merge_request/show';
 
 pactWith(
   {
-    consumer: 'MergeRequest#show',
-    provider: 'Merge Request Discussions Endpoint',
-    log: '../logs/consumer.log',
-    dir: '../contracts/project/merge_request/show',
+    consumer: CONSUMER_NAME,
+    provider: PROVIDER_NAME,
+    log: CONSUMER_LOG,
+    dir: CONTRACT_DIR,
   },
 
   (provider) => {
-    describe('Merge Request Discussions Endpoint', () => {
+    describe(PROVIDER_NAME, () => {
       beforeEach(() => {
         const interaction = {
-          state: 'a merge request with discussions exists',
+          ...Discussions.scenario,
           ...Discussions.request,
           willRespondWith: Discussions.success,
         };
-        return provider.addInteraction(interaction);
+        provider.addInteraction(interaction);
       });
 
-      it('return a successful body', () => {
-        return getDiscussions({
+      it('return a successful body', async () => {
+        const discussions = await getDiscussions({
           url: provider.mockService.baseUrl,
-        }).then((discussions) => {
-          expect(discussions).toEqual(Discussions.body);
         });
+
+        expect(discussions).toEqual(Discussions.body);
       });
     });
   },
diff --git a/doc/development/testing_guide/contract/index.md b/doc/development/testing_guide/contract/index.md
index f61f842e167..30a4adaca44 100644
--- a/doc/development/testing_guide/contract/index.md
+++ b/doc/development/testing_guide/contract/index.md
@@ -50,11 +50,11 @@ Having an organized and sensible folder structure for the test suite makes it ea
 
 The consumer tests are grouped according to the different pages in the application. Each file contains various types of requests found in a page. As such, the consumer test files are named using the Rails standards of how pages are referenced. For example, the project pipelines page would be the `Project::Pipeline#index` page so the equivalent consumer test would be located in `consumer/specs/project/pipelines/index.spec.js`.
 
-When defining the location to output the contract generated by the test, we want to follow the same file structure which would be `contracts/project/pipelines/` for this example. This is the structure in `consumer/endpoints` and `consumer/fixtures` as well.
+When defining the location to output the contract generated by the test, we want to follow the same file structure which would be `contracts/project/pipelines/` for this example. This is the structure in `consumer/resources` and `consumer/fixtures` as well.
 
 #### Provider tests
 
-The provider tests are grouped similarly to our controllers. Each of these tests contains various tests for an API endpoint. For example, the API endpoint to get a list of pipelines for a project would be located in `provider/pact_helpers/project/pipelines/get_list_project_pipelines_helper.rb`. The provider states are structured the same way.
+The provider tests are grouped similarly to our controllers. Each of these tests contains various tests for an API endpoint. For example, the API endpoint to get a list of pipelines for a project would be located in `provider/pact_helpers/project/pipelines/get_list_project_pipelines_helper.rb`. The provider states are grouped according to the different pages in the application similar to the consumer tests.
 
 ### Naming conventions