diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index be8494e19cd4e821160c244914a30a230a9546fe..0386be44be2d5790685541f976cfa47f4c5c8ae8 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -57,7 +57,7 @@ When you find an issue you'd like to work on:
   @docs-hackathon I would like to work on this issue
   ```
 
-You can try installing and running the [Vale linting tool](testing.md#vale)
+You can try installing and running the [Vale linting tool](testing/vale.md)
 and fixing the resulting issues.
 
 ## Ask for help
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 3ecde4e56ae4698875696d61b31600d385a06f3b..39f986deb2d3715f5bd7bfa0a890865f47aaead6 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -65,7 +65,7 @@ the documentation helps others efficiently accomplish tasks and solve problems.
 The GitLab documentation is not localized, but we follow guidelines that help us write for a global audience.
 
 [The GitLab voice](#the-gitlab-voice) dictates that we write clearly and directly with translation in mind.
-Our style guide, [word list](word_list.md), and [Vale rules](../testing.md) ensure consistency in the documentation.
+Our style guide, [word list](word_list.md), and [Vale rules](../testing/index.md) ensure consistency in the documentation.
 
 When documentation is translated into other languages, the meaning of each word must be clear.
 The increasing use of machine translation, GitLab Duo Chat, and other AI tools
@@ -114,7 +114,7 @@ linked style guide. You can't use Kramdown-specific markup (for example, `{:.cla
 For a complete Kramdown reference, see the
 [GitLab Markdown Guide](https://handbook.gitlab.com/handbook/markdown-guide/).
 
-The Markdown format is [tested](../testing.md) by using markdownlint and Vale.
+The Markdown format is tested by using [markdownlint](../testing/markdownlint.md) and [Vale](../testing/vale.md).
 
 ### HTML in Markdown
 
@@ -803,7 +803,7 @@ use a relative file path. For example, `../user/gitlab_com/index.md`.
 Use inline link Markdown markup `[Text](https://example.com)`,
 rather than reference-style links, like `[Text][identifier]`.
 
-Put the entire link on a single line so that [linters](../testing.md) can find it.
+Put the entire link on a single line so that [linters](../testing/index.md) can find it.
 
 ### Links in separate repositories
 
@@ -836,7 +836,7 @@ any related links, search these directories:
 - `app/views/*`
 - `ee/app/views/*`
 
-If you do not fix these links, the [`ui-docs-lint` job](../testing.md#ui-link-tests)
+If you do not fix these links, the [`ui-docs-lint` job](../testing/index.md#tests-in-ui-docs-links-lint)
 in your merge request fails.
 
 ### Text for links
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index 33c4fc378058573808716970d80f2d619fb2c04e..cf5ad29e109b0683466f81d6ec349528b1d9e638 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -231,7 +231,7 @@ when writing about Beta features.
 
 ## blacklist
 
-Do not use **blacklist**. Another option is **denylist**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+Do not use **blacklist**. Another option is **denylist**. ([Vale](../testing/vale.md) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
 
 ## board
 
@@ -305,7 +305,7 @@ If you must refer to the checkbox, you can say it is selected or cleared. For ex
 - Ensure the **Protect environment** checkbox is cleared.
 - Ensure the **Protect environment** checkbox is selected.
 
-(For `deselect`, [Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+(For `deselect`, [Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## checkout, check out
 
@@ -432,7 +432,7 @@ Use:
 ## currently
 
 Do not use **currently** when talking about the product or its features. The documentation describes the product as it is today.
-([Vale](../testing.md#vale) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml))
+([Vale](../testing/vale.md) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml))
 
 ## custom role
 
@@ -528,7 +528,7 @@ Use **inactive** or **off** instead.
 
 ## disallow
 
-Use **prevent** instead of **disallow**. ([Vale](../testing.md#vale) rule: [`Substitutions.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Substitutions.yml))
+Use **prevent** instead of **disallow**. ([Vale](../testing/vale.md) rule: [`Substitutions.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Substitutions.yml))
 
 ## Discussion summary
 
@@ -585,7 +585,7 @@ Do not use **easily**. If the user doesn't find the process to be easy, we lose
 
 ## e.g.
 
-Do not use Latin abbreviations. Use **for example**, **such as**, **for instance**, or **like** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
+Do not use Latin abbreviations. Use **for example**, **such as**, **for instance**, or **like** instead. ([Vale](../testing/vale.md) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
 
 ## ellipsis
 
@@ -602,7 +602,7 @@ Instead of:
 
 ## email
 
-Do not use **e-mail** with a hyphen. When plural, use **emails** or **email messages**. ([Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+Do not use **e-mail** with a hyphen. When plural, use **emails** or **email messages**. ([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## email address
 
@@ -732,7 +732,7 @@ Learn more about [documenting multiple fields at once](index.md#documenting-mult
 
 Use one word for **filename**. When using filename as a variable, use `<filename>`.
 
-([Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## filter
 
@@ -759,11 +759,11 @@ If the **fork relationship** is removed, the
 ## full screen
 
 Use two words for **full screen**.
-([Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## future tense
 
-When possible, use present tense instead of future tense. For example, use **after you execute this command, GitLab displays the result** instead of **after you execute this command, GitLab will display the result**. ([Vale](../testing.md#vale) rule: [`FutureTense.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FutureTense.yml))
+When possible, use present tense instead of future tense. For example, use **after you execute this command, GitLab displays the result** instead of **after you execute this command, GitLab will display the result**. ([Vale](../testing/vale.md) rule: [`FutureTense.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FutureTense.yml))
 
 ## GB, gigabytes
 
@@ -900,7 +900,7 @@ Do not use **Guest permissions**. A user who is assigned the Guest role has a se
 
 ## handy
 
-Do not use **handy**. If the user doesn't find the feature or process to be handy, we lose their trust. ([Vale](../testing.md#vale) rule: [`Simplicity.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Simplicity.yml))
+Do not use **handy**. If the user doesn't find the feature or process to be handy, we lose their trust. ([Vale](../testing/vale.md) rule: [`Simplicity.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Simplicity.yml))
 
 ## high availability, HA
 
@@ -939,11 +939,11 @@ Do not use first-person singular. Use **you** or rewrite the phrase instead.
 
 ## i.e.
 
-Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
+Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing/vale.md) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
 
 ## in order to
 
-Do not use **in order to**. Use **to** instead. ([Vale](../testing.md#vale) rule: [`Wordy.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Wordy.yml))
+Do not use **in order to**. Use **to** instead. ([Vale](../testing/vale.md) rule: [`Wordy.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Wordy.yml))
 
 ## indexes, indices
 
@@ -1132,16 +1132,16 @@ Do not use **Maintainer permissions**. A user who is assigned the Maintainer rol
 
 ## mankind
 
-Do not use **mankind**. Use **people** or **humanity** instead. ([Vale](../testing.md#vale) rule: [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml))
+Do not use **mankind**. Use **people** or **humanity** instead. ([Vale](../testing/vale.md) rule: [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml))
 
 ## manpower
 
-Do not use **manpower**. Use words like **workforce** or **GitLab team members**. ([Vale](../testing.md#vale) rule: [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml))
+Do not use **manpower**. Use words like **workforce** or **GitLab team members**. ([Vale](../testing/vale.md) rule: [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml))
 
 ## master
 
 Do not use **master**. Use **main** when you need a sample [default branch name](#branch).
-([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+([Vale](../testing/vale.md) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
 
 ## may, might
 
@@ -1220,7 +1220,7 @@ Do not use **navigate**. Use **go** instead. For example:
 - Go to this webpage.
 - Open a terminal and go to the `runner` directory.
 
-([Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## need to
 
@@ -1270,7 +1270,7 @@ Instead of:
 - Normally, you specify a certificate.
 - Follow the normal Git workflow.
 
-([Vale](../testing.md#vale) rule: [`Normal.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Normal.yml))
+([Vale](../testing/vale.md) rule: [`Normal.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Normal.yml))
 
 ## note that
 
@@ -1619,7 +1619,7 @@ If you can select multiples of something, then write the word as plural.
 
 ## sanity check
 
-Do not use **sanity check**. Use **check for completeness** instead. ([Vale](../testing.md#vale) rule: [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml))
+Do not use **sanity check**. Use **check for completeness** instead. ([Vale](../testing/vale.md) rule: [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml))
 
 ## scalability
 
@@ -1720,7 +1720,7 @@ Use **authenticated user** instead of **signed-in user** or **signed in user**.
 
 ## simply, simple
 
-Do not use **simply** or **simple**. If the user doesn't find the process to be simple, we lose their trust. ([Vale](../testing.md#vale) rule: [`Simplicity.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Simplicity.yml))
+Do not use **simply** or **simple**. If the user doesn't find the process to be simple, we lose their trust. ([Vale](../testing/vale.md) rule: [`Simplicity.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Simplicity.yml))
 
 ## since
 
@@ -1740,7 +1740,7 @@ Instead of **and/or**, use **or** or re-write the sentence. This rule also appli
 
 ## slave
 
-Do not use **slave**. Another option is **secondary**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+Do not use **slave**. Another option is **secondary**. ([Vale](../testing/vale.md) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
 
 ## storages
 
@@ -1758,7 +1758,7 @@ Gitaly storages have physical paths and virtual storages have virtual paths.
 Use **subgroup** (no hyphen) instead of **sub-group**.
 Also, avoid using alternative terms for subgroups, such as **child group** or **low-level group**.
 
-([Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## subscription tier
 
@@ -1866,11 +1866,11 @@ For examples, see [Prepositions](index.md#prepositions).
 
 ## to-do item
 
-Use lowercase and hyphenate **to-do** item. ([Vale](../testing.md#vale) rule: [`ToDo.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/ToDo.yml))
+Use lowercase and hyphenate **to-do** item. ([Vale](../testing/vale.md) rule: [`ToDo.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/ToDo.yml))
 
 ## To-Do List
 
-Use title case for **To-Do List**. ([Vale](../testing.md#vale) rule: [`ToDo.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/ToDo.yml))
+Use title case for **To-Do List**. ([Vale](../testing/vale.md) rule: [`ToDo.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/ToDo.yml))
 
 ## toggle
 
@@ -1908,7 +1908,7 @@ See the [Microsoft Style Guide](https://learn.microsoft.com/en-us/style-guide/a-
 ## units of measurement
 
 Use a space between the number and the unit of measurement. For example, **128 GB**.
-([Vale](../testing.md#vale) rule: [`Units.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Units.yml))
+([Vale](../testing/vale.md) rule: [`Units.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Units.yml))
 
 For more information, see the
 [Microsoft Style Guide](https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/term-collections/bits-bytes-terms).
@@ -1951,7 +1951,7 @@ For more information, see the [Microsoft Style Guide](https://learn.microsoft.co
 
 ## useful
 
-Do not use **useful**. If the user doesn't find the process to be useful, we lose their trust. ([Vale](../testing.md#vale) rule: [`Simplicity.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Simplicity.yml))
+Do not use **useful**. If the user doesn't find the process to be useful, we lose their trust. ([Vale](../testing/vale.md) rule: [`Simplicity.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Simplicity.yml))
 
 ## user account
 
@@ -1974,7 +1974,7 @@ For example:
 ## utilize
 
 Do not use **utilize**. Use **use** instead. It's more succinct and easier for non-native English speakers to understand.
-([Vale](../testing.md#vale) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
+([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))
 
 ## Value stream forecasting
 
@@ -1984,7 +1984,7 @@ Thereafter, use **Value stream forecasting** by itself.
 
 ## via
 
-Do not use Latin abbreviations. Use **with**, **through**, or **by using** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
+Do not use Latin abbreviations. Use **with**, **through**, or **by using** instead. ([Vale](../testing/vale.md) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
 
 ## Vulnerability resolution
 
@@ -2043,7 +2043,7 @@ Do not use **whilst**. Use [while](#while) instead. **While** is more succinct a
 
 ## whitelist
 
-Do not use **whitelist**. Another option is **allowlist**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+Do not use **whitelist**. Another option is **allowlist**. ([Vale](../testing/vale.md) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
 
 ## yet
 
diff --git a/doc/development/documentation/testing.md b/doc/development/documentation/testing.md
index 7abf40624e0c0c31e456ae42178d3d0155deaa6f..df16840278e69a652edb7b030e1eedf110218f82 100644
--- a/doc/development/documentation/testing.md
+++ b/doc/development/documentation/testing.md
@@ -1,695 +1,11 @@
 ---
-stage: none
-group: Documentation Guidelines
-info: For assistance with this Style Guide page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
-description: Learn how to contribute to GitLab Documentation.
+redirect_to: 'testing/index.md'
+remove_date: '2024-05-19'
 ---
 
-# Documentation testing
+This document was moved to [another location](testing/index.md).
 
-GitLab documentation is stored in projects with code and treated like code. Therefore, we use
-processes similar to those used for code to maintain standards and quality of documentation.
-
-We have tests:
-
-- To lint the words and structure of the documentation.
-- To check the validity of internal links in the documentation suite.
-- To check the validity of links from UI elements, such as files in `app/views` files.
-
-For the specifics of each test run in our CI/CD pipelines, see the configuration for those tests
-in the relevant projects:
-
-- <https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/docs.gitlab-ci.yml>
-- <https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/.gitlab/ci/docs.gitlab-ci.yml>
-- <https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/gitlab-ci-config/gitlab-com.yml>
-- <https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/.gitlab-ci.yml>
-- <https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/master/.gitlab-ci.yml>
-
-We also run some documentation tests in the:
-
-- GitLab CLI project: <https://gitlab.com/gitlab-org/cli/-/blob/main/.gitlab-ci.yml>
-- GitLab Development Kit project:
-  <https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/.gitlab/ci/test.gitlab-ci.yml>.
-- Gitaly project: <https://gitlab.com/gitlab-org/gitaly/-/blob/master/.gitlab-ci.yml>.
-- GitLab Duo Plugin for JetBrains: <https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/blob/main/.gitlab-ci.yml>
-- GitLab VS Code Extension project: <https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/.gitlab-ci.yml>.
-- GitLab Plugin for Neovim project: <https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim/-/blob/main/.gitlab-ci.yml>.
-- GitLab Language Server project: <https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/blob/main/.gitlab-ci.yml>.
-- GitLab Extension for Visual Studio project: <https://gitlab.com/gitlab-org/editor-extensions/gitlab-visual-studio-extension/-/blob/main/.gitlab-ci.yml>.
-
-## Run tests locally
-
-Similar to [previewing your changes locally](review_apps.md), you can also
-run these tests on your local computer. This has the advantage of:
-
-- Speeding up the feedback loop. You can know of any problems with the changes in your branch
-  without waiting for a CI/CD pipeline to run.
-- Lowering costs. Running tests locally is cheaper than running tests on the cloud
-  infrastructure GitLab uses.
-
-To run tests locally, it's important to:
-
-- [Install the tools](#install-linters), and [keep them up to date](#update-linters).
-- Run [linters](#lint-checks), [documentation link tests](#documentation-link-tests), and
-  [UI link tests](#ui-link-tests) the same way they are run in CI/CD pipelines. It's important to use
-  same configuration we use in CI/CD pipelines, which can be different than the default configuration
-  of the tool.
-
-### Lint checks
-
-Merge requests containing changes to Markdown (`.md`) files run a `docs-lint markdown`
-job. This job runs `markdownlint`, and a set of tests from
-[`/scripts/lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/lint-doc.sh)
-that look for page content problems that Vale and markdownlint cannot test for.
-The job fails if any of these tests fail:
-
-- Curl (`curl`) commands must use long-form options (`--header`) instead of short options, like `-h`.
-- Documentation pages must contain front matter indicating ownership of the page.
-- Non-standard Unicode space characters (NBSP, NNBSP, ZWSP) must not be used in documentation,
-  because they can cause irregularities in search indexing and grepping.
-- `CHANGELOG.md` must not contain duplicate versions.
-- No files in the `doc/` directory may be executable.
-- Use `index.md` instead of `README.md`.
-- Directories and filenames must use underscores instead of dashes.
-- Directories and filenames must be in lower case.
-
-#### Run lint checks locally
-
-Lint checks are performed by the [`lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/lint-doc.sh)
-script and can be executed with the help of a Rake task as follows:
-
-1. Go to your `gitlab` directory.
-1. Run:
-
-   ```shell
-   rake lint:markdown
-   ```
-
-To specify a single file or directory you would like to run lint checks for, run:
-
-```shell
-MD_DOC_PATH=path/to/my_doc.md rake lint:markdown
-```
-
-The output should be similar to:
-
-```plaintext
-=> Linting documents at path /path/to/gitlab as <user>...
-=> Checking for cURL short options...
-=> Checking for CHANGELOG.md duplicate entries...
-=> Checking /path/to/gitlab/doc for executable permissions...
-=> Checking for new README.md files...
-=> Linting markdown style...
-=> Linting prose...
-✔ 0 errors, 0 warnings and 0 suggestions in 1 file.
-✔ Linting passed
-```
-
-This requires you to either:
-
-- Have the [required lint tools installed](#local-linters) on your computer.
-- A working Docker or `containerd` installation, to use an image with these tools pre-installed.
-
-### Documentation link tests
-
-Merge requests containing changes to Markdown (`.md`) files run a `docs-lint links`
-job, which runs two types of link checks. In both cases, links with destinations
-that begin with `http` or `https` are considered external links, and skipped:
-
-- `bundle exec nanoc check internal_links`: Tests links to internal pages.
-- `bundle exec nanoc check internal_anchors`: Tests links to topic title anchors on internal pages.
-
-Failures from these tests are displayed at the end of the test results in the **Issues found!** area.
-For example, failures in the `internal_anchors` test follow this format:
-
-```plaintext
-[ ERROR ] internal_anchors - Broken anchor detected!
-  - source file `/tmp/gitlab-docs/public/ee/user/application_security/api_fuzzing/index.html`
-  - destination `/tmp/gitlab-docs/public/ee/development/code_review.html`
-  - link `../../../development/code_review.html#review-response-slo`
-  - anchor `#review-response-slo`
-```
-
-- **Source file**: The full path to the file containing the error. To find the
-  file in the `gitlab` repository, replace `/tmp/gitlab-docs/public/ee` with `doc`, and `.html` with `.md`.
-- **Destination**: The full path to the file not found by the test. To find the
-  file in the `gitlab` repository, replace `/tmp/gitlab-docs/public/ee` with `doc`, and `.html` with `.md`.
-- **Link**: The actual link the script attempted to find.
-- **Anchor**: If present, the topic title anchor the script attempted to find.
-
-Check for multiple instances of the same broken link on each page reporting an error.
-Even if a specific broken link appears multiple times on a page, the test reports it only once.
-
-#### Run document link tests locally
-
-To execute documentation link tests locally:
-
-1. Go to the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory.
-1. Run the following commands:
-
-   ```shell
-   # Check for broken internal links
-   bundle exec nanoc check internal_links
-
-   # Check for broken external links (might take a lot of time to complete).
-   # This test is set to be allowed to fail and is run only in the gitlab-docs project CI
-   bundle exec nanoc check internal_anchors
-   ```
-
-### UI link tests
-
-The `ui-docs-links lint` job uses `haml-lint` to test that all documentation links from
-UI elements (`app/views` files, for example) are linking to valid pages and anchors.
-
-To run the `ui-docs-links` test locally:
-
-1. Open the `gitlab` directory in a terminal window.
-1. Run:
-
-   ```shell
-   bundle exec haml-lint -i DocumentationLinks
-   ```
-
-If you receive an error the first time you run this test, run `bundle install`, which
-installs the dependencies for GitLab, and try again.
-
-If you don't want to install all of the dependencies to test the links, you can:
-
-1. Open the `gitlab` directory in a terminal window.
-1. Install `haml-lint`:
-
-   ```shell
-   gem install haml_lint
-   ```
-
-1. Run:
-
-   ```shell
-   haml-lint -i DocumentationLinks
-   ```
-
-If you manually install `haml-lint` with this process, it does not update automatically
-and you should make sure your version matches the version used by GitLab.
-
-## Update linter configuration
-
-[Vale configuration](#vale) and [markdownlint configuration](#markdownlint) is under source control in each
-project, so updates must be committed to each project individually.
-
-We consider the configuration in the `gitlab` project as the source of truth and that's where all updates should
-first be made.
-
-On a regular basis, the changes made in `gitlab` project to the Vale and markdownlint configuration should be
-synchronized to the other projects. In `omnibus-gitlab`, `gitlab-runner`, and `charts/gitlab`:
-
-1. Create a new branch.
-1. Copy the configuration files from the `gitlab` project into this branch, overwriting
-   the project's old configuration. Make sure no project-specific changes from the `gitlab`
-   project are included. For example, [`RelativeLinks.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/RelativeLinks.yml)
-   is hard coded for specific projects.
-1. Create a merge request and submit it to a technical writer for review and merge.
-
-## Update linting images
-
-Lint tests run in CI/CD pipelines using images from the `gitlab-docs` [container registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry).
-
-If a new version of a dependency is released (like a new version of Ruby), we
-should update the images to use the newer version. Then, we can update the configuration
-files in each of our documentation projects to point to the new image.
-
-To update the linting images:
-
-1. In `gitlab-docs`, open a merge request to update `.gitlab-ci.yml` to use the new tooling
-   version. ([Example MR](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/2571))
-1. When merged, start a `Build docs.gitlab.com every hour` [scheduled pipeline](https://gitlab.com/gitlab-org/gitlab-docs/-/pipeline_schedules).
-1. Go the pipeline you started, and manually run the relevant build-images job,
-   for example, `image:docs-lint-markdown`.
-1. In the job output, get the name of the new image.
-   ([Example job output](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/2335033884#L334))
-1. Verify that the new image was added to the container registry.
-1. Open merge requests to update each of these configuration files to point to the new image.
-   In each merge request, include a small doc update to trigger the job that uses the image.
-   - <https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/docs.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85177))
-   - <https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/.gitlab/ci/test.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3408))
-   - <https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/gitlab-ci-config/gitlab-com.yml> ([Example MR](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6037))
-   - <https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2511))
-   - <https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/master/.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/merge_requests/462))
-   - <https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/.gitlab/ci/test.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/2417))
-1. In each merge request, check the relevant job output to confirm the updated image was
-   used for the test. ([Example job output](https://gitlab.com/gitlab-org/charts/gitlab/-/jobs/2335470260#L24))
-1. Assign the merge requests to any technical writer to review and merge.
-
-## Local linters
-
-To help adhere to the [documentation style guidelines](styleguide/index.md), and improve the content
-added to documentation, [install documentation linters](#install-linters) and
-[integrate them with your code editor](#configure-editors).
-
-At GitLab, we mostly use:
-
-- [markdownlint](#markdownlint)
-- [Vale](#vale)
-
-### markdownlint
-
-[markdownlint](https://github.com/DavidAnson/markdownlint) checks that Markdown syntax follows
-[certain rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules), and is
-used by the `docs-lint` test.
-
-Our [Documentation Style Guide](styleguide/index.md#markdown) and
-[Markdown Guide](https://handbook.gitlab.com/handbook/markdown-guide/) elaborate on which choices must
-be made when selecting Markdown syntax for GitLab documentation. This tool helps catch deviations
-from those guidelines.
-
-markdownlint configuration is found in the following projects:
-
-- [`gitlab`](https://gitlab.com/gitlab-org/gitlab)
-- [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner)
-- [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab)
-- [`charts`](https://gitlab.com/gitlab-org/charts/gitlab)
-- [`gitlab-development-kit`](https://gitlab.com/gitlab-org/gitlab-development-kit)
-- [`gitlab-operator`](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator)
-
-This configuration is also used in build pipelines.
-
-You can use markdownlint:
-
-- On the command line, with either:
-  - [`markdownlint-cli`](https://github.com/igorshubovych/markdownlint-cli#markdownlint-cli).
-  - [`markdownlint-cli2`](https://github.com/DavidAnson/markdownlint-cli2#markdownlint-cli2).
-- [In a code editor](#configure-editors).
-- [In a `pre-push` hook](#configure-pre-push-hooks).
-
-#### Markdown rule `MD044/proper-names` (capitalization)
-
-A rule that can cause confusion is `MD044/proper-names`. The failure, or
-how to correct it, might not be immediately clear.
-This rule checks a list of known words, listed in the `.markdownlint.yml`
-file in each project, to verify proper use of capitalization and backticks.
-Words in backticks are ignored by markdownlint.
-
-In general, product names should follow the exact capitalization of the official
-names of the products, protocols, and so on.
-
-Some examples fail if incorrect capitalization is used:
-
-- MinIO (needs capital `IO`)
-- NGINX (needs all capitals)
-- runit (needs lowercase `r`)
-
-Additionally, commands, parameters, values, filenames, and so on must be
-included in backticks. For example:
-
-- "Change the `needs` keyword in your `.gitlab-ci.yml`..."
-  - `needs` is a parameter, and `.gitlab-ci.yml` is a file, so both need backticks.
-    Additionally, `.gitlab-ci.yml` without backticks fails markdownlint because it
-    does not have capital G or L.
-- "Run `git clone` to clone a Git repository..."
-  - `git clone` is a command, so it must be lowercase, while Git is the product,
-    so it must have a capital G.
-
-### Mermaid
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144328) in GitLab 16.10.
-
-[Mermaid](https://mermaid.js.org/) builds charts and diagrams from code.
-
-The `mermaidlint` job runs on merge requests that contain changes to Markdown files.
-The script (`scripts/lint/check_mermaid.mjs`) returns an error if any Markdown
-files return a Mermaid syntax error.
-
-To help debug your Mermaid charts, use the
-[Mermaid Live Editor](https://mermaid-js.github.io/mermaid-live-editor/edit).
-
-### Vale
-
-[Vale](https://vale.sh/) is a grammar, style, and word usage linter for the
-English language. Vale's configuration is stored in the
-[`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.vale.ini) file located in the root
-directory of projects.
-
-Vale supports creating [custom tests](https://vale.sh/docs/topics/styles/) that extend any of
-several types of checks, which we store in the `.linting/vale/styles/gitlab` directory in the
-documentation directory of projects.
-
-You can find Vale configuration in the following projects:
-
-- [`gitlab`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/.vale/gitlab)
-- [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner/-/tree/main/docs/.vale/gitlab)
-- [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/tree/master/doc/.vale/gitlab)
-- [`charts`](https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/doc/.vale/gitlab)
-- [`gitlab-development-kit`](https://gitlab.com/gitlab-org/gitlab-development-kit/-/tree/main/doc/.vale/gitlab)
-
-This configuration is also used in build pipelines, where
-[error-level rules](#vale-result-types) are enforced.
-
-You can use Vale:
-
-- [On the command line](https://vale.sh/docs/vale-cli/structure/).
-- [In a code editor](#configure-editors).
-- [In a Git hook](#configure-pre-push-hooks). Vale only reports errors in the Git hook (the same
-  configuration as the CI/CD pipelines), and does not report suggestions or warnings.
-
-#### Vale result types
-
-Vale returns three types of results:
-
-- **Error** - For branding guidelines, trademark guidelines, and anything that causes content on
-  the documentation site to render incorrectly.
-- **Warning** - For general style guide rules, tenets, and best practices.
-- **Suggestion** - For technical writing style preferences that may require refactoring of documentation or updates to an exceptions list.
-
-The result types have these attributes:
-
-| Result type  | Displays in CI/CD job output | Displays in MR diff | Causes CI/CD jobs to fail | Vale rule link |
-|--------------|------------------------------|---------------------|---------------------------|----------------|
-| `error`      | **{check-circle}** Yes       | **{check-circle}** Yes | **{check-circle}** Yes | [Error-level Vale rules](https://gitlab.com/search?utf8=✓&snippets=false&scope=&repository_ref=master&search=path%3Adoc%2F.vale%2Fgitlab+Error%3A&group_id=9970&project_id=278964) |
-| `warning`    | **{dotted-circle}** No       | **{check-circle}** Yes | **{dotted-circle}** No | [Warning-level Vale rules](https://gitlab.com/search?utf8=✓&snippets=false&scope=&repository_ref=master&search=path%3Adoc%2F.vale%2Fgitlab+Warning%3A&group_id=9970&project_id=278964) |
-| `suggestion` | **{dotted-circle}** No       | **{dotted-circle}** No | **{dotted-circle}** No | [Suggestion-level Vale rules](https://gitlab.com/search?utf8=✓&snippets=false&scope=&repository_ref=master&search=path%3Adoc%2F.vale%2Fgitlab+Suggestion%3A&group_id=9970&project_id=278964) |
-
-#### Vale spelling test
-
-When Vale flags a valid word as a spelling mistake, you can fix it following these
-guidelines:
-
-| Flagged word                                         | Guideline |
-|------------------------------------------------------|-----------|
-| jargon                                               | Rewrite the sentence to avoid it. |
-| *correctly-capitalized* name of a product or service | Add the word to the [vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt). |
-| name of a person                                     | Remove the name if it's not needed, or [add the vale exception code in-line](#disable-vale-tests). |
-| a command, variable, code, or similar                | Put it in backticks or a code block. For example: ``The git clone command can be used with the CI_COMMIT_BRANCH variable.`` -> ``The `git clone` command can be used with the `CI_COMMIT_BRANCH` variable.`` |
-| UI text from GitLab                                  | Verify it correctly matches the UI, then: If it does not match the UI, update it. If it matches the UI, but the UI seems incorrect, create an issue to see if the UI needs to be fixed. If it matches the UI and seems correct, add it to the [vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt). |
-| UI text from a third-party product                   | Rewrite the sentence to avoid it, or [add the vale exception code in-line](#disable-vale-tests). |
-
-#### Vale uppercase (acronym) test
-
-The [`Uppercase.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Uppercase.yml)
-test checks for incorrect usage of words in all capitals. For example, avoid usage
-like `This is NOT important`.
-
-If the word must be in all capitals, follow these guidelines:
-
-| Flagged word                                                   | Guideline |
-|----------------------------------------------------------------|-----------|
-| Acronym (likely known by the average visitor to that page)     | Add the acronym to the list of words and acronyms in `Uppercase.yml`. |
-| Acronym (likely not known by the average visitor to that page) | The first time the acronym is used, write it out fully followed by the acronym in parentheses. In later uses, use just the acronym by itself. For example: `This feature uses the File Transfer Protocol (FTP). FTP is...`. |
-| Correctly capitalized name of a product or service           | Add the name to the list of words and acronyms in `Uppercase.yml`. |
-| Command, variable, code, or similar                            | Put it in backticks or a code block. For example: ``Use `FALSE` as the variable value.`` |
-| UI text from a third-party product                             | Rewrite the sentence to avoid it, or [add the vale exception code in-line](#disable-vale-tests). |
-
-#### Vale readability score
-
-In [`ReadingLevel.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/ReadingLevel.yml),
-we have implemented
-[the Flesch-Kincaid grade level test](https://readable.com/readability/flesch-reading-ease-flesch-kincaid-grade-level/)
-to determine the readability of our documentation.
-
-As a general guideline, the lower the score, the more readable the documentation.
-For example, a page that scores `12` before a set of changes, and `9` after, indicates an iterative improvement to readability. The score is not an exact science, but is meant to help indicate the
-general complexity level of the page.
-
-The readability score is calculated based on the number of words per sentence, and the number
-of syllables per word. For more information, see [the Vale documentation](https://vale.sh/docs/topics/styles/#metric).
-
-#### When to add a new Vale rule
-
-It's tempting to add a Vale rule for every style guide rule. However, we should be
-mindful of the effort to create and enforce a Vale rule, and the noise it creates.
-
-In general, follow these guidelines:
-
-- If you add an [error-level Vale rule](#vale-result-types), you must fix
-  the existing occurrences of the issue in the documentation before you can add the rule.
-
-  If there are too many issues to fix in a single merge request, add the rule at a
-  `warning` level. Then, fix the existing issues in follow-up merge requests.
-  When the issues are fixed, promote the rule to an `error`.
-
-- If you add a warning-level or suggestion-level rule, consider:
-
-  - How many more warnings or suggestions it creates in the Vale output. If the
-    number of additional warnings is significant, the rule might be too broad.
-
-  - How often an author might ignore it because it's acceptable in the context.
-    If the rule is too subjective, it cannot be adequately enforced and creates
-    unnecessary additional warnings.
-
-  - Whether it's appropriate to display in the merge request diff in the GitLab UI.
-    If the rule is difficult to implement directly in the merge request (for example,
-    it requires page refactoring), set it to suggestion-level so it displays in local editors only.
-
-### Install linters
-
-At a minimum, install [markdownlint](#markdownlint) and [Vale](#vale) to match the checks run in build pipelines.
-
-These tools can be [integrated with your code editor](#configure-editors).
-
-#### Install markdownlint
-
-You can install either `markdownlint-cli` or `markdownlint-cli2` to run `markdownlint`.
-
-To install `markdownlint-cli`, run:
-
-```shell
-yarn global add markdownlint-cli
-```
-
-To install `markdownlint-cli2`, run:
-
-```shell
-yarn global add markdownlint-cli2
-```
-
-You should install the version of `markdownlint-cli` or `markdownlint-cli2`
-[used (see `variables:` section)](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/.gitlab-ci.yml) when building
-the `image:docs-lint-markdown`.
-
-#### Install Vale
-
-Install [`vale`](https://github.com/errata-ai/vale/releases) using either:
-
-- The [`asdf-vale` plugin](https://github.com/pdemagny/asdf-vale) if using [`asdf`](https://asdf-vm.com). In a checkout
-  of a GitLab project with a `.tool-versions` file ([example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.tool-versions)),
-  run:
-
-  ```shell
-  asdf plugin add vale && asdf install vale
-  ```
-
-- A package manager:
-  - macOS using `brew`, run: `brew install vale`.
-  - Linux, use your distribution's package manager or a [released binary](https://github.com/errata-ai/vale/releases).
-
-### Update linters
-
-It's preferable to use linter versions that are the same as those used in our CI/CD pipelines for maximum compatibility
-with the linting rules we use.
-
-To match the versions of `markdownlint-cli` (or `markdownlint-cli2`) and `vale` used in the GitLab projects, refer to:
-
-- For projects managed with `asdf`, the `.tool-versions` file in the project. For example, the
-  [`.tool-versions` file in the `gitlab` project](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.tool-versions).
-- The [versions used (see `variables:` section)](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/.gitlab-ci.yml)
-  when building the `image:docs-lint-markdown` Docker image containing these tools for CI/CD.
-
-Versions set in these two locations should be the same.
-
-| Tool                | Version  | Command                                   | Additional information                                                                       |
-|:--------------------|:---------|:------------------------------------------|:---------------------------------------------------------------------------------------------|
-| `markdownlint-cli`  | Latest   | `yarn global add markdownlint-cli`        | None.                                                                                        |
-| `markdownlint-cli2` | Latest   | `yarn global add markdownlint-cli2`       | None.                                                                                        |
-| `markdownlint-cli`  | Specific | `yarn global add markdownlint-cli@0.35.0` | The `@` indicates a specific version, and this example updates the tool to version `0.35.0`. |
-| `markdownlint-cli2` | Specific | `yarn global add markdownlint-cli2@0.8.1` | The `@` indicates a specific version, and this example updates the tool to version `0.8.1`.  |
-| Vale (using `asdf`) | Specific | `asdf install`                            | Installs the version of Vale set in `.tool-versions` file in a project.                      |
-| Vale (other)        | Specific | Not applicable.                           | Binaries can be [directly downloaded](https://github.com/errata-ai/vale/releases).           |
-| Vale (using `brew`) | Latest   | `brew update && brew upgrade vale`        | This command is for macOS only.                                                              |
-
-### Configure editors
-
-Using linters in your editor is more convenient than having to run the commands from the
-command line.
-
-To configure markdownlint in your editor, install one of the following as appropriate:
-
-- Visual Studio Code [`DavidAnson.vscode-markdownlint` extension](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint).
-- Sublime Text [`SublimeLinter-contrib-markdownlint` package](https://packagecontrol.io/packages/SublimeLinter-contrib-markdownlint).
-  This package uses `markdownlint-cli` by default, but can be configured to use `markdownlint-cli2` with this
-  SublimeLinter configuration:
-
-  ```json
-  "markdownlint": {
-    "executable": [ "markdownlint-cli2" ]
-  }
-  ```
-
-- Vim [ALE plugin](https://github.com/dense-analysis/ale).
-- Emacs [Flycheck extension](https://github.com/flycheck/flycheck). `Flycheck` supports
-  `markdownlint-cli` out of the box, but you must add a `.dir-locals.el` file to
-  point it to the `.markdownlint.yml` at the base of the project directory:
-
-  ```lisp
-  ;; Place this code in a file called `.dir-locals.el` at the root of the gitlab project.
-  ((markdown-mode . ((flycheck-markdown-markdownlint-cli-config . ".markdownlint.yml"))))
-  ```
-
-To configure Vale in your editor, install one of the following as appropriate:
-
-- Visual Studio Code [`ChrisChinchilla.vale-vscode` extension](https://marketplace.visualstudio.com/items?itemName=ChrisChinchilla.vale-vscode).
-  You can configure the plugin to [display only a subset of alerts](#show-subset-of-vale-alerts).
-- Sublime Text [`SublimeLinter-vale` package](https://packagecontrol.io/packages/SublimeLinter-vale). To have Vale
-  suggestions appears as blue instead of red (which is how errors appear), add `vale` configuration to your
-  [SublimeLinter](http://sublimelinter.readthedocs.org) configuration:
-
-  ```json
-  "vale": {
-    "styles": [{
-      "mark_style": "outline",
-      "scope": "region.bluish",
-      "types": ["suggestion"]
-    }]
-  }
-  ```
-
-- [LSP for Sublime Text](https://lsp.sublimetext.io) package [`LSP-vale-ls`](https://packagecontrol.io/packages/LSP-vale-ls).
-- Vim [ALE plugin](https://github.com/dense-analysis/ale).
-- JetBrains IDEs - No plugin exists, but
-  [this issue comment](https://github.com/errata-ai/vale-server/issues/39#issuecomment-751714451)
-  contains tips for configuring an external tool.
-- Emacs [Flycheck extension](https://github.com/flycheck/flycheck). A minimal configuration
-  for Flycheck to work with Vale could look like:
-
-  ```lisp
-  (flycheck-define-checker vale
-    "A checker for prose"
-    :command ("vale" "--output" "line" "--no-wrap"
-              source)
-    :standard-input nil
-    :error-patterns
-      ((error line-start (file-name) ":" line ":" column ":" (id (one-or-more (not (any ":")))) ":" (message)   line-end))
-    :modes (markdown-mode org-mode text-mode)
-    :next-checkers ((t . markdown-markdownlint-cli))
-  )
-
-  (add-to-list 'flycheck-checkers 'vale)
-  ```
-
-  In this setup the `markdownlint` checker is set as a "next" checker from the defined `vale` checker.
-  Enabling this custom Vale checker provides error linting from both Vale and markdownlint.
-
-### Configure pre-push hooks
-
-Git [pre-push hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) allow Git users to:
-
-- Run tests or other processes before pushing a branch.
-- Avoid pushing a branch if failures occur with these tests.
-
-[`lefthook`](https://github.com/Arkweid/lefthook) is a Git hooks manager, making configuring,
-installing, and removing Git hooks simpler.
-
-Configuration for `lefthook` is available in the [`lefthook.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lefthook.yml)
-file for the [`gitlab`](https://gitlab.com/gitlab-org/gitlab) project.
-
-To set up `lefthook` for documentation linting, see
-[Pre-push static analysis](../contributing/style_guides.md#pre-push-static-analysis-with-lefthook).
-
-#### Show Vale warnings on push
-
-By default, `lefthook` shows only Vale errors when pushing changes to a branch. The default branches
-have no Vale errors, so any errors listed here are introduced by commits to the branch.
-
-To also see the Vale warnings when pushing to a branch, set a local environment variable: `VALE_WARNINGS=true`.
-
-Enable Vale warnings on push to improve the documentation suite by:
-
-- Detecting warnings you might be introducing with your commits.
-- Identifying warnings that already exist in the page, which you can resolve to reduce technical debt.
-
-These warnings:
-
-- Don't stop the push from working.
-- Don't result in a broken pipeline.
-- Include all warnings for a file, not just warnings that are introduced by the commits.
-
-To enable Vale warnings on push:
-
-- Automatically, add `VALE_WARNINGS=true` to your shell configuration.
-- Manually, prepend `VALE_WARNINGS=true` to invocations of `lefthook`. For example:
-
-  ```shell
-  VALE_WARNINGS=true bundle exec lefthook run pre-push
-  ```
-
-You can also [configure your editor](#configure-editors) to show Vale warnings.
-
-### Show subset of Vale alerts
-
-You can set Visual Studio Code to display only a subset of Vale alerts when viewing files:
-
-1. Go to **Preferences > Settings > Extensions > Vale**.
-1. In **Vale CLI: Min Alert Level**, select the minimum alert level you want displayed in files.
-
-To display only a subset of Vale alerts when running Vale from the command line, use
-the `--minAlertLevel` flag, which accepts `error`, `warning`, or `suggestion`. Combine it with `--config`
-to point to the configuration file in the project, if needed:
-
-```shell
-vale --config .vale.ini --minAlertLevel error doc/**/*.md
-```
-
-Omit the flag to display all alerts, including `suggestion` level alerts.
-
-### Test one rule at a time
-
-To test only a single rule when running Vale from the command line, modify this
-command, replacing `OutdatedVersions` with the name of the rule:
-
-```shell
-vale --no-wrap --filter='.Name=="gitlab.OutdatedVersions"' doc/**/*.md
-```
-
-### Export Vale results to a file
-
-To export all (or filtered) Vale results to a file, modify this command:
-
-```shell
-# Returns results of types suggestion, warning, and error
-find . -name '*.md' | sort | xargs vale --minAlertLevel suggestion --output line > ../../results.txt
-
-# Returns only warnings and errors
-find . -name '*.md' | sort | xargs vale --minAlertLevel warning --output line > ../../results.txt
-
-# Returns only errors
-find . -name '*.md' | sort | xargs vale --minAlertLevel error --output line > ../../results.txt
-```
-
-These results can be used with the
-[`create_issues.js` script](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/scripts/create_issues.js)
-to generate [documentation-related issues for Hackathons](https://handbook.gitlab.com/handbook/product/ux/technical-writing/workflow/#create-issues-for-a-hackathon).
-
-### Disable Vale tests
-
-You can disable a specific Vale linting rule or all Vale linting rules for any portion of a
-document:
-
-- To disable a specific rule, add a `<!-- vale gitlab.rulename = NO -->` tag before the text, and a
-  `<!-- vale gitlab.rulename = YES -->` tag after the text, replacing `rulename` with the filename of a test in the
-  [GitLab styles](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/.linting/vale/styles/gitlab)
-  directory.
-- To disable all Vale linting rules, add a `<!-- vale off -->` tag before the text, and a
-  `<!-- vale on -->` tag after the text.
-
-Whenever possible, exclude only the problematic rule and lines.
-
-For more information, see
-[Vale's documentation](https://vale.sh/docs/topics/scoping/).
-
-### Disable markdownlint tests
-
-To disable all markdownlint rules, add a `<!-- markdownlint-disable -->` tag before the text, and a
-`<!-- markdownlint-enable -->` tag after the text.
-
-To disable only a [specific rule](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#rules),
-add the rule number to the tag, for example `<!-- markdownlint-disable MD044 -->`
-and `<!-- markdownlint-enable MD044 -->`.
-
-Whenever possible, exclude only the problematic lines.
+<!-- This redirect file can be deleted after <2024-05-19>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/development/documentation/testing/index.md b/doc/development/documentation/testing/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..0ff36e2c09accdb84713dc00f41177f79926e522
--- /dev/null
+++ b/doc/development/documentation/testing/index.md
@@ -0,0 +1,323 @@
+---
+stage: none
+group: Documentation Guidelines
+info: For assistance with this Style Guide page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
+description: Learn how to contribute to GitLab Documentation.
+---
+
+# Documentation testing
+
+GitLab documentation is stored in projects with code, and treated like code.
+To maintain standards and quality of documentation, we use processes similar to
+those used for code.
+
+Merge requests containing changes to Markdown (`.md`) files run these CI/CD jobs:
+
+- `docs-lint markdown`: Tests the documentation content with [Vale](vale.md),
+  the Markdown structure with [markdownlint](markdownlint.md), and other tests
+  [in `lint-docs.sh`](#tests-in-lint-docsh).
+- `docs-lint links`: Checks the validity of internal links in the documentation suite.
+- `mermaidlint`: Checks for invalid Mermaid charts in the documentation.
+- `ui-docs-links lint`: Checks the validity of links from UI elements, such as files in `app/views` files.
+
+## Tests in `lint-doc.sh`
+
+The tests in
+[`/scripts/lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/lint-doc.sh)
+look for page content problems that Vale and markdownlint cannot test for.
+The `docs-lint markdown` job fails if any of these `lint-doc.sh` tests fail:
+
+- Curl (`curl`) commands must use long-form options (`--header`) instead of short options, like `-h`.
+- Documentation pages must contain front matter indicating ownership of the page.
+- Non-standard Unicode space characters (NBSP, NNBSP, ZWSP) must not be used in documentation,
+  because they can cause irregularities in search indexing and grepping.
+- `CHANGELOG.md` must not contain duplicate versions.
+- No files in the `doc/` directory may be executable.
+- Use `index.md` instead of `README.md`.
+- Directories and filenames must use underscores instead of dashes.
+- Directories and filenames must be in lower case.
+
+## Tests in `docs-lint links`
+
+Merge requests containing changes to Markdown (`.md`) files run a `docs-lint links`
+job, which runs two types of link checks. In both cases, links with destinations
+that begin with `http` or `https` are considered external links, and skipped:
+
+- `bundle exec nanoc check internal_links`: Tests links to internal pages.
+- `bundle exec nanoc check internal_anchors`: Tests links to topic title anchors on internal pages.
+
+Failures from these tests are displayed at the end of the test results in the **Issues found!** area.
+For example, failures in the `internal_anchors` test follow this format:
+
+```plaintext
+[ ERROR ] internal_anchors - Broken anchor detected!
+  - source file `/tmp/gitlab-docs/public/ee/user/application_security/api_fuzzing/index.html`
+  - destination `/tmp/gitlab-docs/public/ee/development/code_review.html`
+  - link `../../../development/code_review.html#review-response-slo`
+  - anchor `#review-response-slo`
+```
+
+- **Source file**: The full path to the file containing the error. To find the
+  file in the `gitlab` repository, replace `/tmp/gitlab-docs/public/ee` with `doc`, and `.html` with `.md`.
+- **Destination**: The full path to the file not found by the test. To find the
+  file in the `gitlab` repository, replace `/tmp/gitlab-docs/public/ee` with `doc`, and `.html` with `.md`.
+- **Link**: The actual link the script attempted to find.
+- **Anchor**: If present, the topic title anchor the script attempted to find.
+
+Check for multiple instances of the same broken link on each page reporting an error.
+Even if a specific broken link appears multiple times on a page, the test reports it only once.
+
+## Tests in `mermaidlint`
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144328) in GitLab 16.10.
+
+[Mermaid](https://mermaid.js.org/) builds charts and diagrams from code.
+
+The `mermaidlint` job runs on merge requests that contain changes to Markdown files.
+The script (`scripts/lint/check_mermaid.mjs`) returns an error if any Markdown
+files return a Mermaid syntax error.
+
+To help debug your Mermaid charts, use the
+[Mermaid Live Editor](https://mermaid-js.github.io/mermaid-live-editor/edit).
+
+## Tests in `ui-docs-links lint`
+
+The `ui-docs-links lint` job uses `haml-lint` to test that all documentation links from
+UI elements (`app/views` files, for example) link to valid pages and anchors.
+
+## Install documentation linters
+
+To help adhere to the [documentation style guidelines](../styleguide/index.md), and
+improve the content added to documentation, install documentation linters and
+integrate them with your code editor. At a minimum, install [markdownlint](markdownlint.md)
+and [Vale](vale.md) to match the checks run in build pipelines. Both tools can
+integrate with your code editor.
+
+## Run documentation tests locally
+
+Similar to [previewing your changes locally](../review_apps.md), you can also run
+documentation tests on your local computer. This has the advantage of:
+
+- Speeding up the feedback loop. You can know of any problems with the changes in your branch
+  without waiting for a CI/CD pipeline to run.
+- Lowering costs. Running tests locally is cheaper than running tests on the cloud
+  infrastructure GitLab uses.
+
+It's important to:
+
+- Keep the tools up-to-date, and [match the versions used](#tool-versions-used-in-cicd-pipelines) in our CI/CD pipelines.
+- Run linters, documentation link tests, and UI link tests the same way they are
+  run in CI/CD pipelines. It's important to use same configuration we use in
+  CI/CD pipelines, which can be different than the default configuration of the tool.
+
+### Run Vale or markdownlint locally
+
+Installation and configuration instructions for [markdownlint](markdownlint.md)
+and [Vale](vale.md) are available.
+
+### Run `lint-doc.sh` locally
+
+Use a Rake task to run the `lint-doc.sh` tests locally.
+
+Prerequisites:
+
+- You have either:
+  - The [required lint tools installed](#install-documentation-linters) on your computer.
+  - A working Docker or `containerd` installation, to use an image with these tools pre-installed.
+
+1. Go to your `gitlab` directory.
+1. Run:
+
+   ```shell
+   rake lint:markdown
+   ```
+
+To specify a single file or directory you would like to run lint checks for, run:
+
+```shell
+MD_DOC_PATH=path/to/my_doc.md rake lint:markdown
+```
+
+The output should be similar to:
+
+```plaintext
+=> Linting documents at path /path/to/gitlab as <user>...
+=> Checking for cURL short options...
+=> Checking for CHANGELOG.md duplicate entries...
+=> Checking /path/to/gitlab/doc for executable permissions...
+=> Checking for new README.md files...
+=> Linting markdown style...
+=> Linting prose...
+✔ 0 errors, 0 warnings and 0 suggestions in 1 file.
+✔ Linting passed
+```
+
+### Run documentation link tests locally
+
+To test links in the documentation locally:
+
+1. Go to the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory.
+1. Run the following commands:
+
+   ```shell
+   # Check for broken internal links
+   bundle exec nanoc check internal_links
+
+   # Check for broken external links (might take a lot of time to complete).
+   # This test is allowed to fail, and is run only in the gitlab-docs project CI
+   bundle exec nanoc check internal_anchors
+   ```
+
+### Run UI link tests locally
+
+To test documentation links in the GitLab UI locally:
+
+1. Open the `gitlab` directory in a terminal window.
+1. Run:
+
+   ```shell
+   bundle exec haml-lint -i DocumentationLinks
+   ```
+
+If you receive an error the first time you run this test, run `bundle install`, which
+installs the dependencies for GitLab, and try again.
+
+If you don't want to install all of the dependencies to test the links, you can:
+
+1. Open the `gitlab` directory in a terminal window.
+1. Install `haml-lint`:
+
+   ```shell
+   gem install haml_lint
+   ```
+
+1. Run:
+
+   ```shell
+   haml-lint -i DocumentationLinks
+   ```
+
+If you manually install `haml-lint` with this process, it does not update automatically
+and you should make sure your version matches the version used by GitLab.
+
+## Update linter configuration
+
+Vale and markdownlint configurations are under source control in each
+project, so updates must be committed to each project individually.
+
+The configuration in the `gitlab` project should be treated as the source of truth,
+and all updates should first be made there.
+
+On a regular basis, the changes made in `gitlab` project to the Vale and markdownlint configuration should be
+synchronized to the other projects. In each of the [supported projects](#supported-projects):
+
+1. Create a new branch.
+1. Copy the configuration files from the `gitlab` project into this branch, overwriting
+   the project's old configuration. Make sure no project-specific changes from the `gitlab`
+   project are included. For example, [`RelativeLinks.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/RelativeLinks.yml)
+   is hard coded for specific projects.
+1. Create a merge request and submit it to a technical writer for review and merge.
+
+## Update linting images
+
+Lint tests run in CI/CD pipelines using images from the
+`gitlab-docs` [container registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry).
+
+If a new version of a dependency is released (like a new version of Ruby), we
+should update the images to use the newer version. Then, we can update the configuration
+files in each of our documentation projects to point to the new image.
+
+To update the linting images:
+
+1. In `gitlab-docs`, open a merge request to update `.gitlab-ci.yml` to use the new tooling
+   version. ([Example MR](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/2571))
+1. When merged, start a `Build docs.gitlab.com every hour` [scheduled pipeline](https://gitlab.com/gitlab-org/gitlab-docs/-/pipeline_schedules).
+1. Go the pipeline you started, and manually run the relevant build-images job,
+   for example, `image:docs-lint-markdown`.
+1. In the job output, get the name of the new image.
+   ([Example job output](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/2335033884#L334))
+1. Verify that the new image was added to the container registry.
+1. Open merge requests to update each of these configuration files to point to the new image.
+   In each merge request, include a small doc update to trigger the job that uses the image.
+   - <https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/docs.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85177))
+   - <https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/.gitlab/ci/test.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3408))
+   - <https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/gitlab-ci-config/gitlab-com.yml> ([Example MR](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6037))
+   - <https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2511))
+   - <https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/master/.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/merge_requests/462))
+   - <https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/.gitlab/ci/test.gitlab-ci.yml> ([Example MR](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/2417))
+1. In each merge request, check the relevant job output to confirm the updated image was
+   used for the test. ([Example job output](https://gitlab.com/gitlab-org/charts/gitlab/-/jobs/2335470260#L24))
+1. Assign the merge requests to any technical writer to review and merge.
+
+## Configure pre-push hooks
+
+Git [pre-push hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) allow Git users to:
+
+- Run tests or other processes before pushing a branch.
+- Avoid pushing a branch if failures occur with these tests.
+
+[`lefthook`](https://github.com/Arkweid/lefthook) is a Git hooks manager. It makes configuring,
+installing, and removing Git hooks simpler. Configuration for it is available in the
+[`lefthook.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lefthook.yml)
+file for the [`gitlab`](https://gitlab.com/gitlab-org/gitlab) project.
+
+To set up `lefthook` for documentation linting, see
+[Pre-push static analysis](../../contributing/style_guides.md#pre-push-static-analysis-with-lefthook).
+
+To show Vale errors on push, see [Show Vale warnings on push](vale.md#show-vale-warnings-on-push).
+
+## Disable linting on documentation
+
+Some, but not all, linting can be disabled on documentation files:
+
+- [Vale tests can be disabled](vale.md#disable-vale-tests) for all or part of a file.
+- [`markdownlint` tests can be disabled](markdownlint.md#disable-markdownlint-tests) for all or part of a file.
+- [Documentation link tests](#run-documentation-link-tests-locally) cannot be disabled.
+- [UI link tests](#run-ui-link-tests-locally) cannot be disabled.
+
+## Tool versions used in CI/CD pipelines
+
+It's preferable to use linter versions that are the same as those used in our CI/CD pipelines for maximum compatibility
+with the linting rules we use.
+
+To match the versions of `markdownlint-cli` (or `markdownlint-cli2`) and `vale` used in the GitLab projects, refer to:
+
+- For projects managed with `asdf`, the `.tool-versions` file in the project. For example, the
+  [`.tool-versions` file in the `gitlab` project](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.tool-versions).
+- The [versions used (see `variables:` section)](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/.gitlab-ci.yml)
+  when building the `image:docs-lint-markdown` Docker image containing these tools for CI/CD.
+
+Versions set in these two locations should be the same.
+
+| Tool                | Version  | Command                                   | Additional information |
+|---------------------|----------|-------------------------------------------|------------------------|
+| `markdownlint-cli`  | Latest   | `yarn global add markdownlint-cli`        | None.                  |
+| `markdownlint-cli2` | Latest   | `yarn global add markdownlint-cli2`       | None.                  |
+| `markdownlint-cli`  | Specific | `yarn global add markdownlint-cli@0.35.0` | The `@` indicates a specific version, and this example updates the tool to version `0.35.0`. |
+| `markdownlint-cli2` | Specific | `yarn global add markdownlint-cli2@0.8.1` | The `@` indicates a specific version, and this example updates the tool to version `0.8.1`. |
+| Vale (using `asdf`) | Specific | `asdf install`                            | Installs the version of Vale set in `.tool-versions` file in a project. |
+| Vale (other)        | Specific | Not applicable.                           | Binaries can be [directly downloaded](https://github.com/errata-ai/vale/releases). |
+| Vale (using `brew`) | Latest   | `brew update && brew upgrade vale`        | This command is for macOS only. |
+
+## Supported projects
+
+For the specifics of each test run in our CI/CD pipelines, see the configuration for those tests
+in the relevant projects:
+
+- <https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/docs.gitlab-ci.yml>
+- <https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/.gitlab/ci/docs.gitlab-ci.yml>
+- <https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/gitlab-ci-config/gitlab-com.yml>
+- <https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/.gitlab-ci.yml>
+- <https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/master/.gitlab-ci.yml>
+
+We also run some documentation tests in the:
+
+- GitLab CLI project: <https://gitlab.com/gitlab-org/cli/-/blob/main/.gitlab-ci.yml>
+- GitLab Development Kit project:
+  <https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/.gitlab/ci/test.gitlab-ci.yml>.
+- Gitaly project: <https://gitlab.com/gitlab-org/gitaly/-/blob/master/.gitlab-ci.yml>.
+- GitLab Duo Plugin for JetBrains: <https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/blob/main/.gitlab-ci.yml>
+- GitLab VS Code Extension project: <https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/.gitlab-ci.yml>.
+- GitLab Plugin for Neovim project: <https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim/-/blob/main/.gitlab-ci.yml>.
+- GitLab Language Server project: <https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/blob/main/.gitlab-ci.yml>.
+- GitLab Extension for Visual Studio project: <https://gitlab.com/gitlab-org/editor-extensions/gitlab-visual-studio-extension/-/blob/main/.gitlab-ci.yml>.
diff --git a/doc/development/documentation/testing/markdownlint.md b/doc/development/documentation/testing/markdownlint.md
new file mode 100644
index 0000000000000000000000000000000000000000..3b842e9c9513e9a1e8127bd1eb5f92c3bd34a6f6
--- /dev/null
+++ b/doc/development/documentation/testing/markdownlint.md
@@ -0,0 +1,125 @@
+---
+stage: none
+group: Documentation Guidelines
+info: For assistance with this Style Guide page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
+description: Learn how to contribute to GitLab Documentation.
+---
+
+# markdownlint documentation tests
+
+[markdownlint](https://github.com/DavidAnson/markdownlint) checks that Markdown syntax follows
+[certain rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules), and is
+used by the `docs-lint` test.
+
+Our [Documentation Style Guide](../styleguide/index.md#markdown) and
+[Markdown Guide](https://handbook.gitlab.com/handbook/markdown-guide/) elaborate on which choices must
+be made when selecting Markdown syntax for GitLab documentation. This tool helps catch deviations
+from those guidelines.
+
+markdownlint configuration is found in the following projects:
+
+- [`gitlab`](https://gitlab.com/gitlab-org/gitlab)
+- [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner)
+- [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab)
+- [`charts`](https://gitlab.com/gitlab-org/charts/gitlab)
+- [`gitlab-development-kit`](https://gitlab.com/gitlab-org/gitlab-development-kit)
+- [`gitlab-operator`](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator)
+
+This configuration is also used in build pipelines.
+
+You can use markdownlint:
+
+- On the command line, with either:
+  - [`markdownlint-cli`](https://github.com/igorshubovych/markdownlint-cli#markdownlint-cli).
+  - [`markdownlint-cli2`](https://github.com/DavidAnson/markdownlint-cli2#markdownlint-cli2).
+- [In a code editor](#configure-markdownlint-in-your-editor).
+- [In a `pre-push` hook](index.md#configure-pre-push-hooks).
+
+## Install markdownlint
+
+You can install either `markdownlint-cli` or `markdownlint-cli2` to run `markdownlint`.
+
+To install `markdownlint-cli`, run:
+
+```shell
+yarn global add markdownlint-cli
+```
+
+To install `markdownlint-cli2`, run:
+
+```shell
+yarn global add markdownlint-cli2
+```
+
+You should install the version of `markdownlint-cli` or `markdownlint-cli2`
+[used (see `variables:` section)](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/.gitlab-ci.yml) when building
+the `image:docs-lint-markdown`.
+
+## Configure markdownlint in your editor
+
+Using markdownlint in your editor is more convenient than having to run the commands from the
+command line.
+
+To configure markdownlint in your editor, install one of the following as appropriate:
+
+- Visual Studio Code [`DavidAnson.vscode-markdownlint` extension](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint).
+- Sublime Text [`SublimeLinter-contrib-markdownlint` package](https://packagecontrol.io/packages/SublimeLinter-contrib-markdownlint).
+  This package uses `markdownlint-cli` by default, but can be configured to use `markdownlint-cli2` with this
+  SublimeLinter configuration:
+
+  ```json
+  "markdownlint": {
+    "executable": [ "markdownlint-cli2" ]
+  }
+  ```
+
+- Vim [ALE plugin](https://github.com/dense-analysis/ale).
+- Emacs [Flycheck extension](https://github.com/flycheck/flycheck). `Flycheck` supports
+  `markdownlint-cli` out of the box, but you must add a `.dir-locals.el` file to
+  point it to the `.markdownlint.yml` at the base of the project directory:
+
+  ```lisp
+  ;; Place this code in a file called `.dir-locals.el` at the root of the gitlab project.
+  ((markdown-mode . ((flycheck-markdown-markdownlint-cli-config . ".markdownlint.yml"))))
+  ```
+
+## Disable markdownlint tests
+
+To disable all markdownlint rules, add a `<!-- markdownlint-disable -->` tag before the text, and a
+`<!-- markdownlint-enable -->` tag after the text.
+
+To disable only a [specific rule](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#rules),
+add the rule number to the tag, for example `<!-- markdownlint-disable MD044 -->`
+and `<!-- markdownlint-enable MD044 -->`.
+
+Whenever possible, exclude only the problematic lines.
+
+## Troubleshooting
+
+### Markdown rule `MD044/proper-names` (capitalization)
+
+A rule that can cause confusion is `MD044/proper-names`. The failure, or
+how to correct it, might not be immediately clear.
+This rule checks a list of known words, listed in the `.markdownlint.yml`
+file in each project, to verify proper use of capitalization and backticks.
+Words in backticks are ignored by markdownlint.
+
+In general, product names should follow the exact capitalization of the official
+names of the products, protocols, and so on.
+
+Some examples fail if incorrect capitalization is used:
+
+- MinIO (needs capital `IO`)
+- NGINX (needs all capitals)
+- runit (needs lowercase `r`)
+
+Additionally, commands, parameters, values, filenames, and so on must be
+included in backticks. For example:
+
+- "Change the `needs` keyword in your `.gitlab-ci.yml`..."
+  - `needs` is a parameter, and `.gitlab-ci.yml` is a file, so both need backticks.
+    Additionally, `.gitlab-ci.yml` without backticks fails markdownlint because it
+    does not have capital G or L.
+- "Run `git clone` to clone a Git repository..."
+  - `git clone` is a command, so it must be lowercase, while Git is the product,
+    so it must have a capital G.
diff --git a/doc/development/documentation/testing/vale.md b/doc/development/documentation/testing/vale.md
new file mode 100644
index 0000000000000000000000000000000000000000..5da3962733fd0b68580797f6b5e339a3a08437c3
--- /dev/null
+++ b/doc/development/documentation/testing/vale.md
@@ -0,0 +1,281 @@
+---
+stage: none
+group: Documentation Guidelines
+info: For assistance with this Style Guide page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
+description: Learn how to contribute to GitLab Documentation.
+---
+
+# Vale documentation tests
+
+[Vale](https://vale.sh/) is a grammar, style, and word usage linter for the
+English language. Vale's configuration is stored in the
+[`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.vale.ini) file located in the root
+directory of projects.
+
+Vale supports creating [custom tests](https://vale.sh/docs/topics/styles/) that extend any of
+several types of checks, which we store in the `.linting/vale/styles/gitlab` directory in the
+documentation directory of projects.
+
+Some example Vale configurations:
+
+- [`gitlab`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/.vale/gitlab)
+- [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner/-/tree/main/docs/.vale/gitlab)
+- [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/tree/master/doc/.vale/gitlab)
+- [`charts`](https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/doc/.vale/gitlab)
+- [`gitlab-development-kit`](https://gitlab.com/gitlab-org/gitlab-development-kit/-/tree/main/doc/.vale/gitlab)
+
+This configuration is also used in build pipelines, where
+[error-level rules](#result-types) are enforced.
+
+You can use Vale:
+
+- [On the command line](https://vale.sh/docs/vale-cli/structure/).
+- [In a code editor](#configure-vale-in-your-editor).
+- [In a Git hook](index.md#configure-pre-push-hooks). Vale only reports errors in the Git hook (the same
+  configuration as the CI/CD pipelines), and does not report suggestions or warnings.
+
+## Install Vale
+
+Install [`vale`](https://github.com/errata-ai/vale/releases) using either:
+
+- If using [`asdf`](https://asdf-vm.com), the [`asdf-vale` plugin](https://github.com/pdemagny/asdf-vale). In a checkout
+  of a GitLab project with a `.tool-versions` file ([example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.tool-versions)),
+  run:
+
+  ```shell
+  asdf plugin add vale && asdf install vale
+  ```
+
+- A package manager:
+  - macOS using `brew`, run: `brew install vale`.
+  - Linux, use your distribution's package manager or a [released binary](https://github.com/errata-ai/vale/releases).
+
+## Configure Vale in your editor
+
+Using linters in your editor is more convenient than having to run the commands from the
+command line.
+
+To configure Vale in your editor, install one of the following as appropriate:
+
+- Visual Studio Code [`ChrisChinchilla.vale-vscode` extension](https://marketplace.visualstudio.com/items?itemName=ChrisChinchilla.vale-vscode).
+  You can configure the plugin to [display only a subset of alerts](#limit-which-tests-are-run).
+- Sublime Text [`SublimeLinter-vale` package](https://packagecontrol.io/packages/SublimeLinter-vale). To have Vale
+  suggestions appears as blue instead of red (which is how errors appear), add `vale` configuration to your
+  [SublimeLinter](http://sublimelinter.readthedocs.org) configuration:
+
+  ```json
+  "vale": {
+    "styles": [{
+      "mark_style": "outline",
+      "scope": "region.bluish",
+      "types": ["suggestion"]
+    }]
+  }
+  ```
+
+- [LSP for Sublime Text](https://lsp.sublimetext.io) package [`LSP-vale-ls`](https://packagecontrol.io/packages/LSP-vale-ls).
+- Vim [ALE plugin](https://github.com/dense-analysis/ale).
+- JetBrains IDEs - No plugin exists, but
+  [this issue comment](https://github.com/errata-ai/vale-server/issues/39#issuecomment-751714451)
+  contains tips for configuring an external tool.
+- Emacs [Flycheck extension](https://github.com/flycheck/flycheck). A minimal configuration
+  for Flycheck to work with Vale could look like:
+
+  ```lisp
+  (flycheck-define-checker vale
+    "A checker for prose"
+    :command ("vale" "--output" "line" "--no-wrap"
+              source)
+    :standard-input nil
+    :error-patterns
+      ((error line-start (file-name) ":" line ":" column ":" (id (one-or-more (not (any ":")))) ":" (message)   line-end))
+    :modes (markdown-mode org-mode text-mode)
+    :next-checkers ((t . markdown-markdownlint-cli))
+  )
+
+  (add-to-list 'flycheck-checkers 'vale)
+  ```
+
+  In this setup the `markdownlint` checker is set as a "next" checker from the defined `vale` checker.
+  Enabling this custom Vale checker provides error linting from both Vale and markdownlint.
+
+## Result types
+
+Vale returns three types of results:
+
+- **Error** - For branding guidelines, trademark guidelines, and anything that causes content on
+  the documentation site to render incorrectly.
+- **Warning** - For general style guide rules, tenets, and best practices.
+- **Suggestion** - For technical writing style preferences that may require refactoring of documentation or updates to an exceptions list.
+
+The result types have these attributes:
+
+| Result type  | Displays in CI/CD job output | Displays in MR diff | Causes CI/CD jobs to fail | Vale rule link |
+|--------------|------------------------------|---------------------|---------------------------|----------------|
+| `error`      | **{check-circle}** Yes       | **{check-circle}** Yes | **{check-circle}** Yes | [Error-level Vale rules](https://gitlab.com/search?utf8=✓&snippets=false&scope=&repository_ref=master&search=path%3Adoc%2F.vale%2Fgitlab+Error%3A&group_id=9970&project_id=278964) |
+| `warning`    | **{dotted-circle}** No       | **{check-circle}** Yes | **{dotted-circle}** No | [Warning-level Vale rules](https://gitlab.com/search?utf8=✓&snippets=false&scope=&repository_ref=master&search=path%3Adoc%2F.vale%2Fgitlab+Warning%3A&group_id=9970&project_id=278964) |
+| `suggestion` | **{dotted-circle}** No       | **{dotted-circle}** No | **{dotted-circle}** No | [Suggestion-level Vale rules](https://gitlab.com/search?utf8=✓&snippets=false&scope=&repository_ref=master&search=path%3Adoc%2F.vale%2Fgitlab+Suggestion%3A&group_id=9970&project_id=278964) |
+
+## When to add a new Vale rule
+
+It's tempting to add a Vale rule for every style guide rule. However, we should be
+mindful of the effort to create and enforce a Vale rule, and the noise it creates.
+
+In general, follow these guidelines:
+
+- If you add an [error-level Vale rule](#result-types), you must fix
+  the existing occurrences of the issue in the documentation before you can add the rule.
+
+  If there are too many issues to fix in a single merge request, add the rule at a
+  `warning` level. Then, fix the existing issues in follow-up merge requests.
+  When the issues are fixed, promote the rule to an `error`.
+
+- If you add a warning-level or suggestion-level rule, consider:
+
+  - How many more warnings or suggestions it creates in the Vale output. If the
+    number of additional warnings is significant, the rule might be too broad.
+
+  - How often an author might ignore it because it's acceptable in the context.
+    If the rule is too subjective, it cannot be adequately enforced and creates
+    unnecessary additional warnings.
+
+  - Whether it's appropriate to display in the merge request diff in the GitLab UI.
+    If the rule is difficult to implement directly in the merge request (for example,
+    it requires page refactoring), set it to suggestion-level so it displays in local editors only.
+
+## Limit which tests are run
+
+You can set Visual Studio Code to display only a subset of Vale alerts when viewing files:
+
+1. Go to **Preferences > Settings > Extensions > Vale**.
+1. In **Vale CLI: Min Alert Level**, select the minimum alert level you want displayed in files.
+
+To display only a subset of Vale alerts when running Vale from the command line, use
+the `--minAlertLevel` flag, which accepts `error`, `warning`, or `suggestion`. Combine it with `--config`
+to point to the configuration file in the project, if needed:
+
+```shell
+vale --config .vale.ini --minAlertLevel error doc/**/*.md
+```
+
+Omit the flag to display all alerts, including `suggestion` level alerts.
+
+### Test one rule at a time
+
+To test only a single rule when running Vale from the command line, modify this
+command, replacing `OutdatedVersions` with the name of the rule:
+
+```shell
+vale --no-wrap --filter='.Name=="gitlab.OutdatedVersions"' doc/**/*.md
+```
+
+## Disable Vale tests
+
+You can disable a specific Vale linting rule or all Vale linting rules for any portion of a
+document:
+
+- To disable a specific rule, add a `<!-- vale gitlab.rulename = NO -->` tag before the text, and a
+  `<!-- vale gitlab.rulename = YES -->` tag after the text, replacing `rulename` with the filename of a test in the
+  [GitLab styles](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/.linting/vale/styles/gitlab)
+  directory.
+- To disable all Vale linting rules, add a `<!-- vale off -->` tag before the text, and a
+  `<!-- vale on -->` tag after the text.
+
+Whenever possible, exclude only the problematic rule and lines.
+
+For more information, see
+[Vale's documentation](https://vale.sh/docs/topics/scoping/).
+
+## Show Vale warnings on push
+
+By default, `lefthook` shows only Vale errors when pushing changes to a branch. The default branches
+have no Vale errors, so any errors listed here are introduced by commits to the branch.
+
+To also see the Vale warnings when pushing to a branch, set a local environment variable: `VALE_WARNINGS=true`.
+
+Enable Vale warnings on push to improve the documentation suite by:
+
+- Detecting warnings you might be introducing with your commits.
+- Identifying warnings that already exist in the page, which you can resolve to reduce technical debt.
+
+These warnings:
+
+- Don't stop the push from working.
+- Don't result in a broken pipeline.
+- Include all warnings for a file, not just warnings that are introduced by the commits.
+
+To enable Vale warnings on push:
+
+- Automatically, add `VALE_WARNINGS=true` to your shell configuration.
+- Manually, prepend `VALE_WARNINGS=true` to invocations of `lefthook`. For example:
+
+  ```shell
+  VALE_WARNINGS=true bundle exec lefthook run pre-push
+  ```
+
+You can also [configure your editor](#configure-vale-in-your-editor) to show Vale warnings.
+
+## Resolve problems Vale identifies
+
+### Spelling test
+
+When Vale flags a valid word as a spelling mistake, you can fix it following these
+guidelines:
+
+| Flagged word                                         | Guideline |
+|------------------------------------------------------|-----------|
+| jargon                                               | Rewrite the sentence to avoid it. |
+| *correctly-capitalized* name of a product or service | Add the word to the [Vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt). |
+| name of a person                                     | Remove the name if it's not needed, or [add the Vale exception code inline](#disable-vale-tests). |
+| a command, variable, code, or similar                | Put it in backticks or a code block. For example: ``The git clone command can be used with the CI_COMMIT_BRANCH variable.`` -> ``The `git clone` command can be used with the `CI_COMMIT_BRANCH` variable.`` |
+| UI text from GitLab                                  | Verify it correctly matches the UI, then: If it does not match the UI, update it. If it matches the UI, but the UI seems incorrect, create an issue to see if the UI needs to be fixed. If it matches the UI and seems correct, add it to the [Vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt). |
+| UI text from a third-party product                   | Rewrite the sentence to avoid it, or [add the Vale exception code in-line](#disable-vale-tests). |
+
+#### Uppercase (acronym) test
+
+The [`Uppercase.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Uppercase.yml)
+test checks for incorrect usage of words in all capitals. For example, avoid usage
+like `This is NOT important`.
+
+If the word must be in all capitals, follow these guidelines:
+
+| Flagged word                                                   | Guideline |
+|----------------------------------------------------------------|-----------|
+| Acronym (likely known by the average visitor to that page)     | Add the acronym to the list of words and acronyms in `Uppercase.yml`. |
+| Acronym (likely not known by the average visitor to that page) | The first time the acronym is used, write it out fully followed by the acronym in parentheses. In later uses, use just the acronym by itself. For example: `This feature uses the File Transfer Protocol (FTP). FTP is...`. |
+| Correctly capitalized name of a product or service           | Add the name to the list of words and acronyms in `Uppercase.yml`. |
+| Command, variable, code, or similar                            | Put it in backticks or a code block. For example: ``Use `FALSE` as the variable value.`` |
+| UI text from a third-party product                             | Rewrite the sentence to avoid it, or [add the vale exception code in-line](#disable-vale-tests). |
+
+### Readability score
+
+In [`ReadingLevel.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/ReadingLevel.yml),
+we have implemented
+[the Flesch-Kincaid grade level test](https://readable.com/readability/flesch-reading-ease-flesch-kincaid-grade-level/)
+to determine the readability of our documentation.
+
+As a general guideline, the lower the score, the more readable the documentation.
+For example, a page that scores `12` before a set of changes, and `9` after, indicates an iterative improvement to readability. The score is not an exact science, but is meant to help indicate the
+general complexity level of the page.
+
+The readability score is calculated based on the number of words per sentence, and the number
+of syllables per word. For more information, see [the Vale documentation](https://vale.sh/docs/topics/styles/#metric).
+
+## Export Vale results to a file
+
+To export all (or filtered) Vale results to a file, modify this command:
+
+```shell
+# Returns results of types suggestion, warning, and error
+find . -name '*.md' | sort | xargs vale --minAlertLevel suggestion --output line > ../../results.txt
+
+# Returns only warnings and errors
+find . -name '*.md' | sort | xargs vale --minAlertLevel warning --output line > ../../results.txt
+
+# Returns only errors
+find . -name '*.md' | sort | xargs vale --minAlertLevel error --output line > ../../results.txt
+```
+
+These results can be used with the
+[`create_issues.js` script](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/scripts/create_issues.js)
+to generate [documentation-related issues for Hackathons](https://handbook.gitlab.com/handbook/product/ux/technical-writing/workflow/#create-issues-for-a-hackathon).