Merge branch 'docs-anchors6-ci-ee' into 'master'

Docs: (EE Port) Fix CI/CD related anchors

See merge request gitlab-org/gitlab-ee!9741

doc/README.md

@@ -279,7 +279,7 @@ The following documentation relates to the DevOps **Release** stage:
 | [Canary Deployments](user/project/canary_deployments.md) **[PREMIUM]**                                          | Employ a popular CI strategy where a small portion of the fleet is updated to the new version first.                                  |
 | [Deploy Boards](user/project/deploy_boards.md) **[PREMIUM]**                                                    | View the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. |
 | [Environments and deployments](ci/environments.md)                                                              | With environments, you can control the continuous deployment of your software within GitLab.                                          |
-| [Environment-specific variables](ci/variables/README.md#limiting-environment-scopes-of-variables) **[PREMIUM]** | Limit scope of variables to specific environments.                                                                                    |
+| [Environment-specific variables](ci/variables/README.md#limiting-environment-scopes-of-variables-premium) **[PREMIUM]** | Limit scope of variables to specific environments.                                                                                    |
 | [GitLab CI/CD](ci/README.md)                                                                                    | Explore the features and capabilities of Continuous Deployment and Delivery with GitLab.                                              |
 | [GitLab Pages](user/project/pages/index.md)                                                                     | Build, test, and deploy a static site directly from GitLab.                                                                           |
 | [Protected Runners](ci/runners/README.md#protected-runners)                                                     | Select Runners to only pick jobs for protected branches and tags.                                                                     |

doc/ci/README.md

@@ -48,7 +48,7 @@ into more features:
 | [Introduction to pipelines and jobs](pipelines.md)                                                     | Provides an overview of GitLab CI/CD and jobs.                                                                               |
 | [CI/CD Variables](variables/README.md)                                                                 | How environment variables can be configured and made available in pipelines.                                                 |
 | [Where variables can be used](variables/where_variables_can_be_used.md)                                | A deeper look into where and how CI/CD variables can be used.                                                                |
-| [User](../user/permissions.md#gitlab-ci) and [job](../user/permissions.md#job-permissions) permissions | Learn about the access levels a user can have for performing certain CI actions.                                             |
+| [User](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions | Learn about the access levels a user can have for performing certain CI actions.                                             |
 | [Configuring GitLab Runners](runners/README.md)                                                        | Documentation for configuring [GitLab Runner](https://docs.gitlab.com/runner/).                                              |
 | [Introduction to environments and deployments](environments.md)                                        | Learn how to separate your jobs into environments and use them for different purposes like testing, building and, deploying. |
 | [Job artifacts](../user/project/pipelines/job_artifacts.md)                                            | Learn about the output of jobs.                                                                                              |

doc/ci/chatops/README.md

@@ -12,7 +12,7 @@ GitLab ChatOps provides a method to interact with CI/CD jobs through chat servic
 
 GitLab ChatOps is built upon two existing features, [GitLab CI/CD](../README.md) and [Slack Slash Commmands](../../user/project/integrations/slack_slash_commands.md).
 
-A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [.gitlab-ci.yml](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.html#predefined-variables-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
+A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [.gitlab-ci.yml](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.html#predefined-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
 
 After the job has finished, its output is sent back to Slack provided it has completed within 30 minutes. If a job takes more than 30 minutes to run it must use the Slack API to manually send data back to a channel.
 

doc/ci/ci_cd_for_external_repos/github_integration.md

 # Using GitLab CI/CD with a GitHub repository **[PREMIUM]**
 
 GitLab CI/CD can be used with **GitHub.com** and **GitHub Enterprise** by
-creating a [CI/CD project][cicd-projects] to connect your GitHub repository to
+creating a [CI/CD project](../../user/project/ci_cd_for_external_repo.md) to connect your GitHub repository to
 GitLab.
 
 NOTE: **Note:**
@@ -10,7 +10,7 @@ manual method.
 
 ## Connect with GitHub integration
 
-If the [GitHub integration][github-integration] has been enabled by your GitLab
+If the [GitHub integration](../../integration/github.md) has been enabled by your GitLab
 administrator:
 
 NOTE: **Note:**
@@ -29,10 +29,10 @@ for more information.
 
     ![Create project](img/github_repo_list.png)
 
-1. In GitHub, add a `.gitlab-ci.yml` to [configure GitLab CI/CD][ci-quickstart].
+1. In GitHub, add a `.gitlab-ci.yml` to [configure GitLab CI/CD](../quick_start/README.md).
 
-GitLab will import the project, enable [Pull Mirroring][pull-mirroring], enable
-[GitHub project integration][github-project-integration], and create a web hook
+GitLab will import the project, enable [Pull Mirroring](../../workflow/repository_mirroring.md#pulling-from-a-remote-repository-starter), enable
+[GitHub project integration](../../user/project/integrations/github.md), and create a web hook
 on GitHub to notify GitLab of new commits.
 
 ## Connect with Personal Access Token
@@ -40,7 +40,7 @@ on GitHub to notify GitLab of new commits.
 NOTE: **Note:** Personal access tokens can only be used to connect GitHub.com
 repositories to GitLab.
 
-If you are not using the [GitHub integration][github-integration], you can
+If you are not using the [GitHub integration](../../integration/github.md), you can
 still perform a one-off authorization with GitHub to grant GitLab access your
 repositories:
 
@@ -60,15 +60,15 @@ repositories:
 1. Paste the token into the **Personal access token** field and click **List
    Repositories**. Click **Connect** to select the repository.
 
-1. In GitHub, add a `.gitlab-ci.yml` to [configure GitLab CI/CD][ci-quickstart].
+1. In GitHub, add a `.gitlab-ci.yml` to [configure GitLab CI/CD](../quick_start/README.md).
 
-GitLab will import the project, enable [Pull Mirroring][pull-mirroring], enable
-[GitHub project integration][github-project-integration], and create a web hook
+GitLab will import the project, enable [Pull Mirroring](../../workflow/repository_mirroring.md#pulling-from-a-remote-repository-starter), enable
+[GitHub project integration](../../user/project/integrations/github.md), and create a web hook
 on GitHub to notify GitLab of new commits.
 
 ## Connect manually
 
-If the [GitHub integration][github-integration] is not enabled, or is enabled
+If the [GitHub integration](../../integration/github.md) is not enabled, or is enabled
 for a different GitHub instance, you GitLab CI/CD can be manually enabled for
 your repository.
 
@@ -86,7 +86,7 @@ your repository.
 
     GitLab will automatically configure polling-based pull mirroring.
 
-1. Still in GitLab, enable the [GitHub project integration][github-project-integration]
+1. Still in GitLab, enable the [GitHub project integration](../../user/project/integrations/github.md)
    from **Settings > Integrations.**
 
     Check the **Active** checkbox to enable the integration, paste your
@@ -99,7 +99,7 @@ your repository.
    new commits.
 
     The web hook URL should be set to the GitLab API to
-    [trigger pull mirroring][pull-mirroring-trigger],
+    [trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
     using the GitLab personal access token we just created.
 
     ```
@@ -109,10 +109,3 @@ your repository.
     ![Create web hook](img/github_push_webhook.png)
 
 1. In GitHub add a `.gitlab-ci.yml` to configure GitLab CI/CD.
-
-[ci-quickstart]: ../quick_start/README.md
-[cicd-projects]: ../../user/project/ci_cd_for_external_repo.md
-[github-integration]: ../../integration/github.md
-[github-project-integration]: ../../user/project/integrations/github.md
-[pull-mirroring]: ../../workflow/repository_mirroring.md#pulling-from-a-remote-repository-starter
-[pull-mirroring-trigger]: ../../api/projects.md#start-the-pull-mirroring-process-for-a-project

doc/ci/examples/dependency_scanning.md

@@ -63,7 +63,7 @@ be automatically extracted and shown right in the merge request widget.
 
 ## Supported languages and package managers
 
-See [the full list of supported languages and package managers](../../user/project/merge_requests/dependency_scanning.md#supported-languages-and-frameworks).
+See [the full list of supported languages and package managers](../../user/project/merge_requests/dependency_scanning.md#supported-languages-and-dependency-managers).
 
 ## Previous job definitions
 

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -4,6 +4,7 @@ author_gitlab: blitzgren
 level: intermediate
 article_type: tutorial
 date: 2018-03-07
+last_updated: 2019-03-06
 ---
 
 # DevOps and Game Dev with GitLab CI/CD
@@ -520,7 +521,7 @@ a lot of breathing room in quickly getting changes to players.
 Here are some ideas to further investigate that can speed up or improve your pipeline:
 
 - [Yarn](https://yarnpkg.com) instead of npm
-- Set up a custom [Docker](../../../ci/docker/using_docker_images.md#define-image-and-services-from-gitlab-ci-yml) image that can preload dependencies and tools (like AWS CLI)
+- Set up a custom [Docker](../../../ci/docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) image that can preload dependencies and tools (like AWS CLI)
 - Forward a [custom domain](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) to your game's S3 static website
 - Combine jobs if you find it unnecessary for a small project
 - Avoid the queues and set up your own [custom GitLab CI/CD runner](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/)

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -5,6 +5,7 @@ author_gitlab: mehranrasulian
 level: intermediate
 article_type: tutorial
 date: 2017-08-31
+last_updated: 2019-03-06
 ---
 
 # Test and deploy Laravel applications with GitLab CI/CD and Envoy
@@ -374,7 +375,7 @@ You might want to create another Envoy task to do that for you.
 We also create the `.env` file in the same path to set up our production environment variables for Laravel.
 These are persistent data and will be shared to every new release.
 
-Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments.md), which will be described [later](#setting-up-gitlab-ci-cd) in this tutorial.
+Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments.md), which will be described [later](#setting-up-gitlab-cicd) in this tutorial.
 
 Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `master` branch.
 To keep things simple, we commit directly to `master`, without using [feature-branches](../../../workflow/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
@@ -557,7 +558,7 @@ So we should adjust the configuration of MySQL instance by defining `MYSQL_DATAB
 Find out more about MySQL variables at the [official MySQL Docker Image](https://hub.docker.com/r/_/mysql/).
 
 Also set the variables `DB_HOST` to `mysql` and `DB_USERNAME` to `root`, which are Laravel specific variables.
-We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-build).
+We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-job).
 
 ```yaml
 ...

doc/ci/examples/test-scala-application.md

@@ -55,8 +55,8 @@ You can use other versions of Scala and SBT by defining them in
 
 Add the `Coverage was \[\d+.\d+\%\]` regular expression in the
 **Settings ➔ Pipelines ➔ Coverage report** project setting to
-retrieve the [test coverage] rate from the build trace and have it
-displayed with your jobs.
+retrieve the [test coverage](../../user/project/pipelines/settings.md#test-coverage-report-badge)
+rate from the build trace and have it displayed with your jobs.
 
 **Pipelines** must be enabled for this option to appear.
 
@@ -69,8 +69,5 @@ in the `.gitlab-ci.yml` file with your application's name.
 ## Heroku API key
 
 You can look up your Heroku API key in your
-[account](https://dashboard.heroku.com/account). Add a secure [variable] with
+[account](https://dashboard.heroku.com/account). Add a [protected variable](../variables/README.md#protected-variables) with
 this value in **Project ➔ Variables** with key `HEROKU_API_KEY`.
-
-[variable]: ../variables/README.md#user-defined-variables-secure-variables
-[test coverage]: ../../user/project/pipelines/settings.md#test-coverage-report-badge

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -4,6 +4,7 @@ author_gitlab: Hostert
 level: beginner
 article_type: tutorial
 date: 2018-02-20
+last_updated: 2019-03-06
 ---
 
 # Testing a Phoenix application with GitLab CI/CD
@@ -177,7 +178,7 @@ environment it can run. Since we will work with a single environment, we'll edit
 configuration file (`test.exs`).
 
 But, why do we need to adjust our configuration? Well, GitLab CI/CD builds and tests our code in one
-isolated virtual machine, called [Runner][runner-site], using Docker technology. In this Runner,
+isolated virtual machine, called [Runner](../../runners/README.md), using Docker technology. In this Runner,
 GitLab CI/CD has access to everything our Phoenix application need to run, exactly as we have in our
 `localhost`, but we have to tell GitLab CI/CD where to create and find this database using system
 variables. This way, GitLab CI/CD will create our test database inside the Runner, just like we do
@@ -417,7 +418,6 @@ other reasons][ci-reasons] to keep using GitLab CI/CD. The benefits to our teams
 [ci-docs]: ../../README.md "GitLab CI/CD Documentation"
 [skipping-jobs]: ../../yaml/README.md#skipping-jobs "Skipping Jobs"
 [gitlab-runners]: ../../runners/README.md "GitLab Runners Documentation"
-[runner-site]: ../../runners/README.md#runners "Runners"
 [docker-image]: https://hub.docker.com/r/trenpixster/elixir/ "Elixir Docker Image"
 [using-docker]: ../../docker/using_docker_images.md "Using Docker Images"
 [hello-gitlab]: https://gitlab.com/Hostert/hello_gitlab_ci "Hello GitLab CI/CD"

doc/ci/permissions/README.md

-This document was moved to [user/permissions.md](../../user/permissions.md#gitlab-ci).
+---
+redirect_to: '../../user/permissions.md#gitlab-cicd-permissions'
+---
+
+This document was moved to [user/permissions.md](../../user/permissions.md#gitlab-cicd-permissions).

doc/ci/review_apps/index.md

@@ -13,7 +13,7 @@ Review Apps:
 
 - Provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests.
 - Allow designers and product manages to see your changes without needing to check out your branch and run your changes in a sandbox environment.
-- Are fully integrated with the [GitLab DevOps LifeCycle](../../README.md#complete-devops-with-gitlab).
+- Are fully integrated with the [GitLab DevOps LifeCycle](../../README.md#the-entire-devops-lifecycle).
 - Allow you to deploy your changes wherever you want.
 
 ![Review Apps Workflow](img/continuous-delivery-review-apps.svg)

doc/ci/services/README.md

@@ -10,4 +10,4 @@ be linked with your base image. Below is a list of examples you may use.
 - [Using MySQL](mysql.md)
 - [Using PostgreSQL](postgres.md)
 - [Using Redis](redis.md)
-- [Using Other Services](../docker/using_docker_images.md#how-to-use-other-images-as-services)
+- [Using Other Services](../docker/using_docker_images.md#what-is-a-service)

doc/ci/services/postgres.md

@@ -31,7 +31,7 @@ Database: nice_marmot
 ```
 
 If you are wondering why we used `postgres` for the `Host`, read more at
-[How is service linked to the job](../docker/using_docker_images.md#how-is-service-linked-to-the-job).
+[How services are linked to the job](../docker/using_docker_images.md#how-services-are-linked-to-the-job).
 
 You can also use any other docker image available on [Docker Hub][hub-pg].
 For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`.

doc/ci/triggers/README.md

@@ -4,7 +4,7 @@
 >
 > - [Introduced](https://about.gitlab.com/2015/08/22/gitlab-7-14-released/) in GitLab 7.14.
 > - GitLab 8.12 has a completely redesigned job permissions system. Read all
->   about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers).
+>   about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#pipeline-triggers).
 
 Triggers can be used to force a pipeline rerun of a specific `ref` (branch or
 tag) with an API call.
@@ -30,7 +30,7 @@ in [GitLab Premium][ee] 9.3.
 
 This way of triggering can only be used when invoked inside `.gitlab-ci.yml`,
 and it creates a dependent pipeline relation visible on the
-[pipeline graph](../pipelines.md#multi-project-pipelines-graphs). For example:
+[pipeline graph](../pipelines.md#multi-project-pipelines-graphs-premium). For example:
 
 ```yaml
 build_docs:
@@ -276,7 +276,7 @@ Old triggers, created before GitLab 9.0 will be marked as legacy.
 Triggers with the legacy label do not have an associated user and only have
 access to the current project. They are considered deprecated and will be
 removed with one of the future versions of GitLab. You are advised to
-[take ownership](#taking-ownership) of any legacy triggers.
+[take ownership](#taking-ownership-of-a-trigger) of any legacy triggers.
 
 [ee-2017]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2017
 [ee-2346]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2346

doc/ci/variables/README.md

@@ -16,7 +16,7 @@ Variables of different types can take precedence over other variables, depending
 
 The order of precedence for variables is (from highest to lowest):
 
-1. [Trigger variables](../triggers/README.md#pass-job-variables-to-a-trigger) or [scheduled pipeline variables](../../user/project/pipelines/schedules.md#making-use-of-scheduled-pipeline-variables).
+1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables) or [scheduled pipeline variables](../../user/project/pipelines/schedules.md#making-use-of-scheduled-pipeline-variables).
 1. Project-level [variables](#variables) or [protected variables](#protected-variables).
 1. Group-level [variables](#variables) or [protected variables](#protected-variables).
 1. YAML-defined [job-level variables](../yaml/README.md#variables).
@@ -46,7 +46,7 @@ version of Runner required.
 
 NOTE: **Note:**
 Starting with GitLab 9.0, we have deprecated some variables. Read the
-[9.0 Renaming](#9-0-renaming) section to find out their replacements. **You are
+[9.0 Renaming](#gitlab-90-renaming) section to find out their replacements. **You are
 strongly advised to use the new variables as we will remove the old ones in
 future GitLab releases.**
 
@@ -331,7 +331,7 @@ variables that were set, etc.
 
 Before enabling this, you should ensure jobs are visible to
 [team members only](../../user/permissions.md#project-features). You should
-also [erase](../pipelines.md#seeing-build-status) all generated job traces
+also [erase](../pipelines.md#seeing-job-status) all generated job traces
 before making them visible again.
 
 To enable debug traces, set the `CI_DEBUG_TRACE` variable to `true`:

doc/ci/variables/where_variables_can_be_used.md

@@ -106,11 +106,11 @@ The following variables are known as "persisted":
 
 They are:
 
-- Supported for definitions where the ["Expansion place"](#gitlab-ci-yml-file) is:
+- Supported for definitions where the ["Expansion place"](#gitlab-ciyml-file) is:
   - Runner.
   - Script execution shell.
 - Not supported:
-  - For definitions where the ["Expansion place"](#gitlab-ci-yml-file) is GitLab.
+  - For definitions where the ["Expansion place"](#gitlab-ciyml-file) is GitLab.
   - In the `only` and `except` [variables expressions](README.md#variables-expressions).
 
 ## Variables with an environment scope

doc/user/admin_area/settings/continuous_integration.md

@@ -26,7 +26,7 @@ If you want to disable it for a specific project, you can do so in
 
 The maximum size of the [job artifacts](../../../administration/job_artifacts.md)
 can be set in the Admin area of your GitLab instance. The value is in *MB* and
-the default is 100MB per job; on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-ci-cd).
+the default is 100MB per job; on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
 
 To change it:
 
@@ -40,7 +40,7 @@ The default expiration time of the [job artifacts](../../../administration/job_a
 can be set in the Admin area of your GitLab instance. The syntax of duration is
 described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in)
 and the default value is `30 days`. On GitLab.com they
-[never expire](../../gitlab_com/index.md#gitlab-ci-cd).
+[never expire](../../gitlab_com/index.md#gitlab-cicd).
 
 1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
 1. Change the value of default expiration time.

doc/user/gitlab_com/index.md

@@ -51,7 +51,7 @@ Below are the settings for [GitLab Pages].
 | TLS certificates support| yes               | no            |
 
 The maximum size of your Pages site is regulated by the artifacts maximum size
-which is part of [GitLab CI/CD](#gitlab-ci-cd).
+which is part of [GitLab CI/CD](#gitlab-cicd).
 
 ## GitLab CI/CD
 

doc/user/group/clusters/index.md

@@ -72,11 +72,10 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
 
 ## Environment scopes **[PREMIUM]**
 
-When adding more than one Kubernetes cluster to your project, you need
-to differentiate them with an environment scope. The environment scope
-associates clusters with [environments](../../../ci/environments.md)
-similar to how the [environment-specific
-variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
+When adding more than one Kubernetes cluster to your project, you need to differentiate
+them with an environment scope. The environment scope associates clusters with
+[environments](../../../ci/environments.md) similar to how the
+[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables-premium)
 work.
 
 While evaluating which environment matches the environment scope of a

doc/user/project/clusters/index.md

@@ -477,12 +477,9 @@ differentiate the new cluster with the rest.
 
 ## Setting the environment scope **[PREMIUM]**
 
-When adding more than one Kubernetes clusters to your project, you need
-to differentiate them with an environment scope. The environment scope
-associates clusters with [environments](../../../ci/environments.md)
-similar to how the [environment-specific
-variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables)
-work.
+When adding more than one Kubernetes cluster to your project, you need to differentiate
+them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments.md) similar to how the
+[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-variables-premium) work.
 
 The default environment scope is `*`, which means all jobs, regardless of their
 environment, will use that cluster. Each scope can only be used by a single
@@ -545,7 +542,7 @@ GitLab CI/CD build environment.
 | `KUBE_CA_PEM_FILE` | Path to a file containing PEM data. Only present if a custom CA bundle was specified. |
 | `KUBE_CA_PEM` | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. |
 | `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This config also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. |
-| `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](#base-domain) for more information. | 
+| `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](#base-domain) for more information. |
 
 NOTE: **NOTE:**
 Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main

doc/user/project/integrations/prometheus.md

@@ -13,7 +13,7 @@ There are two ways to set up Prometheus integration, depending on where your app
 - For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes).
 - For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus).
 
-Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-ci-cd-environments). You are also able to [add your own metrics](#adding-additional-metrics-premium) as well.
+Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-cicd-environments). You are also able to [add your own metrics](#adding-additional-metrics-premium) as well.
 
 ## Enabling Prometheus Integration
 

doc/user/project/merge_requests/index.md

@@ -34,7 +34,7 @@ With GitLab merge requests, you can:
 With **[GitLab Enterprise Edition][ee]**, you can also:
 
 - Prepare a full review and submit it once it's ready with [Merge Request Reviews](../../discussions/index.md#merge-request-reviews-premium) **[PREMIUM]**
-- View the deployment process across projects with [Multi-Project Pipelines](../../../ci/multi_project_pipelines.md#multi-project-pipeline-graphs) **[PREMIUM]**
+- View the deployment process across projects with [Multi-Project Pipelines](../../../ci/multi_project_pipelines.md) **[PREMIUM]**
 - Request [approvals](merge_request_approvals.md) from your managers **[STARTER]**
 - Analyze the impact of your changes with [Code Quality reports](code_quality.md) **[STARTER]**
 - Manage the licenses of your dependencies with [License Management](#license-management-ultimate) **[ULTIMATE]**

doc/user/project/new_ci_build_permissions_model.md

@@ -49,7 +49,7 @@ It is important to note that we have a few types of users:
   Administrator will have to be a member of it in order to have access to it
   via another project's job.
 
-- **External users**: CI jobs created by [external users][ext] will have
+- **External users**: CI jobs created by [external users](../permissions.md#external-users-permissions) will have
   access only to projects to which user has at least reporter access. This
   rules out accessing all internal projects by default,
 
@@ -60,7 +60,7 @@ Let's consider the following scenario:
    hosted in private repositories and you have multiple CI jobs that make use
    of these repositories.
 
-1. You invite a new [external user][ext]. CI jobs created by that user do not
+1. You invite a new [external user](../permissions.md#external-users-permissions). CI jobs created by that user do not
    have access to internal repositories, because the user also doesn't have the
    access from within GitLab. You as an employee have to grant explicit access
    for this user. This allows us to prevent from accidental data leakage.
@@ -232,7 +232,6 @@ test:
 
 [job permissions]: ../permissions.md#job-permissions
 [comment]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22484#note_16648302
-[ext]: ../permissions.md#external-users
 [gitsub]: ../../ci/git_submodules.md
 [https]: ../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols
 [triggers]: ../../ci/triggers/README.md

doc/user/project/pages/introduction.md

@@ -115,7 +115,7 @@ gives you absolute control over the build process. You can actually watch your
 website being built live by following the CI job traces.
 
 For a simplified user guide on setting up GitLab CI/CD for Pages, read through
-the article [GitLab Pages from A to Z: Part 4 - Creating and Tweaking `.gitlab-ci.yml` for GitLab Pages](getting_started_part_four.md#creating-and-tweaking-gitlab-ci-yml-for-gitlab-pages)
+the article [GitLab Pages from A to Z: Part 4 - Creating and Tweaking `.gitlab-ci.yml` for GitLab Pages](getting_started_part_four.md)
 
 > **Note:**
 > Before reading this section, make sure you familiarize yourself with GitLab CI

doc/user/project/pipelines/job_artifacts.md

@@ -183,7 +183,7 @@ information in the UI.
 DANGER: **Warning:**
 This is a destructive action that leads to data loss. Use with caution.
 
-If you have at least Developer [permissions](../../permissions.md#gitlab-ci-cd-permissions)
+If you have at least Developer [permissions](../../permissions.md#gitlab-cicd-permissions)
 on the project, you can erase a single job via the UI which will also remove the
 artifacts and the job's trace.