Add latest changes from gitlab-org/gitlab@master

14 files changed, 200 insertions, 80 deletions

diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
index 962cc28bf30..512501f72ba 100644
--- a/doc/ci/pipelines/multi_project_pipelines.md
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -230,6 +230,96 @@ In the upstream pipeline:
          artifacts: true
    ```
 
+#### Pass artifacts to a downstream pipeline
+
+You can pass artifacts to a downstream pipeline by using [`needs:project`](../yaml/index.md#needsproject).
+
+1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
+1. Trigger the downstream pipeline with a trigger job:
+
+   ```yaml
+   build_artifacts:
+     stage: build
+     script:
+       - echo "This is a test artifact!" >> artifact.txt
+     artifacts:
+       paths:
+         - artifact.txt
+
+   deploy:
+     stage: deploy
+     trigger: my/downstream_project
+   ```
+
+1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
+   by using `needs:project`. Set `job` to the job in the upstream pipeline to fetch artifacts from,
+   `ref` to the branch, and `artifacts: true`.
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - cat artifact.txt
+     needs:
+       - project: my/upstream_project
+         job: build_artifacts
+         ref: main
+         artifacts: true
+   ```
+
+#### Pass artifacts to a downstream pipeline from a Merge Request pipeline
+
+When you use `needs:project` to [pass artifacts to a downstream pipeline](#pass-artifacts-to-a-downstream-pipeline),
+the `ref` value is usually a branch name, like `main` or `development`.
+
+For merge request pipelines, the `ref` value is in the form of `refs/merge-requests/<id>/head`,
+where `id` is the merge request ID. You can retrieve this ref with the [`CI_MERGE_REQUEST_REF_PATH`](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
+CI/CD variable. Do not use a branch name as the `ref` with merge request pipelines,
+because the downstream pipeline attempts to fetch artifacts from the latest branch pipeline.
+
+To fetch the artifacts from the upstream `merge request` pipeline instead of the `branch` pipeline,
+pass this variable to the downstream pipeline using variable inheritance:
+
+1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
+1. In the job that triggers the downstream pipeline, pass the `$CI_MERGE_REQUEST_REF_PATH` variable by using
+   [variable inheritance](#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword):
+
+   ```yaml
+   build_artifacts:
+     stage: build
+     script:
+       - echo "This is a test artifact!" >> artifact.txt
+     artifacts:
+       paths:
+         - artifact.txt
+
+   upstream_job:
+     variables:
+       UPSTREAM_REF: $CI_MERGE_REQUEST_REF_PATH
+     trigger:
+       project: my/downstream_project
+       branch: my-branch
+   ```
+
+1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
+   by using `needs:project`. Set the `ref` to the `UPSTREAM_REF` variable, and `job`
+   to the job in the upstream pipeline to fetch artifacts from:
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - cat artifact.txt
+     needs:
+       - project: my/upstream_project
+         job: build_artifacts
+         ref: UPSTREAM_REF
+         artifacts: true
+   ```
+
+This method works for fetching artifacts from a regular merge request parent pipeline,
+but fetching artifacts from [merge results](merged_results_pipelines.md) pipelines is not supported.
+
 #### Use `rules` or `only`/`except` with multi-project pipelines
 
 You can use CI/CD variables or the [`rules`](../yaml/index.md#rulesif) keyword to
diff --git a/doc/ci/yaml/includes.md b/doc/ci/yaml/includes.md
index 838710834ba..5158f80ea64 100644
--- a/doc/ci/yaml/includes.md
+++ b/doc/ci/yaml/includes.md
@@ -289,10 +289,10 @@ smoke-test-job:
 
 In `include` sections in your `.gitlab-ci.yml` file, you can use:
 
-- [Project variables](../variables/index.md#add-a-cicd-variable-to-a-project)
-- [Group variables](../variables/index.md#add-a-cicd-variable-to-a-group)
-- [Instance variables](../variables/index.md#add-a-cicd-variable-to-an-instance)
-- Project [predefined variables](../variables/predefined_variables.md)
+- [Project variables](../variables/index.md#add-a-cicd-variable-to-a-project).
+- [Group variables](../variables/index.md#add-a-cicd-variable-to-a-group).
+- [Instance variables](../variables/index.md#add-a-cicd-variable-to-an-instance).
+- Project [predefined variables](../variables/predefined_variables.md).
 - In GitLab 14.2 and later, the `$CI_COMMIT_REF_NAME` [predefined variable](../variables/predefined_variables.md).
 
   When used in `include`, the `CI_COMMIT_REF_NAME` variable returns the full
@@ -322,7 +322,11 @@ include:
   file: '.compliance-gitlab-ci.yml'
 ```
 
-For an example of how you can include these predefined variables, and the variables' impact on CI/CD jobs,
+You cannot use variables defined in jobs, or in a global [`variables`](../yaml/index.md#variables)
+section which defines the default variables for all jobs. Includes are evaluated before jobs,
+so these variables cannot be used with `include`.
+
+For an example of how you can include predefined variables, and the variables' impact on CI/CD jobs,
 see this [CI/CD variable demo](https://youtu.be/4XR8gw3Pkos).
 
 ## Use `rules` with `include`
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 1d1640b9b51..d6fb118f4af 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -171,11 +171,11 @@ Use `include:local` instead of symbolic links.
 
 **Possible inputs**:
 
-- A full path relative to the root directory (`/`).
+A full path relative to the root directory (`/`):
+
 - The YAML file must have the extension `.yml` or `.yaml`.
 - You can [use `*` and `**` wildcards in the file path](includes.md#use-includelocal-with-wildcard-file-paths).
-
-CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
+- You can use [certain CI/CD variables](includes.md#use-variables-with-include).
 
 **Example of `include:local`**:
 
@@ -208,10 +208,10 @@ use `include:file`. You can use `include:file` in combination with `include:proj
 
 **Possible inputs**:
 
-- A full path, relative to the root directory (`/`). The YAML file must have the
-  extension `.yml` or `.yaml`.
+A full path, relative to the root directory (`/`):
 
-CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
+- The YAML file must have the extension `.yml` or `.yaml`.
+- You can use [certain CI/CD variables](includes.md#use-variables-with-include).
 
 **Example of `include:file`**:
 
@@ -268,10 +268,11 @@ Use `include:remote` with a full URL to include a file from a different location
 
 **Possible inputs**:
 
-- A public URL accessible by an HTTP/HTTPS `GET` request. Authentication with the
-  remote URL is not supported. The YAML file must have the extension `.yml` or `.yaml`.
+A public URL accessible by an HTTP/HTTPS `GET` request:
 
-CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
+- Authentication with the remote URL is not supported.
+- The YAML file must have the extension `.yml` or `.yaml`.
+- You can use [certain CI/CD variables](includes.md#use-variables-with-include).
 
 **Example of `include:remote`**:
 
@@ -296,9 +297,12 @@ Use `include:template` to include [`.gitlab-ci.yml` templates](https://gitlab.co
 
 **Possible inputs**:
 
-- [`.gitlab-ci.yml` templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
+A [CI/CD template](../examples/index.md#cicd-templates):
 
-CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
+- Templates are stored in [`lib/gitlab/ci/templates`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
+  Not all templates are designed to be used with `include:template`, so check template
+  comments before using one.
+- You can use [certain CI/CD variables](includes.md#use-variables-with-include).
 
 **Example of `include:template`**:
 
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
 
diff --git a/doc/gitlab-basics/start-using-git.md b/doc/gitlab-basics/start-using-git.md
index 65680227ad0..c6de723246c 100644
--- a/doc/gitlab-basics/start-using-git.md
+++ b/doc/gitlab-basics/start-using-git.md
@@ -391,7 +391,7 @@ git checkout <default-branch>
 git merge <feature-branch>
 ```
 
-In GitLab, you typically use a [merge request](../user/project/merge_requests/) to merge your changes, instead of using the command line.
+In GitLab, you typically use a [merge request](../user/project/merge_requests/index.md) to merge your changes, instead of using the command line.
 
 To create a merge request from a fork to an upstream repository, see the
 [forking workflow](../user/project/repository/forking_workflow.md).
diff --git a/doc/raketasks/spdx.md b/doc/raketasks/spdx.md
index 18f058f695e..81da52bc327 100644
--- a/doc/raketasks/spdx.md
+++ b/doc/raketasks/spdx.md
@@ -19,6 +19,6 @@ sudo gitlab-rake gitlab:spdx:import
 bundle exec rake gitlab:spdx:import RAILS_ENV=production
 ```
 
-To perform this task in the [offline environment](../user/application_security/offline_deployments/#defining-offline-environments),
+To perform this task in the [offline environment](../user/application_security/offline_deployments/index.md#defining-offline-environments),
 an outbound connection to [`licenses.json`](https://spdx.org/licenses/licenses.json) should be
 allowed.
diff --git a/doc/security/index.md b/doc/security/index.md
index 73ac5028db5..7d5cb9653b1 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -30,6 +30,6 @@ type: index
 
 ## Securing your GitLab installation
 
-Consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/) to harden your GitLab instance and minimize the risk of unwanted user account creation.
+Consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) to harden your GitLab instance and minimize the risk of unwanted user account creation.
 
 Self-hosting GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.