From 7421e6f9f2b5889b05738af7eba568af6ae3fcbc Mon Sep 17 00:00:00 2001
From: GitLab Bot <gitlab-bot@gitlab.com>
Date: Mon, 30 Mar 2020 06:07:59 +0000
Subject: Add latest changes from gitlab-org/gitlab@master

---
 .../bitbucket_integration.md                       |  4 +--
 doc/ci/ci_cd_for_external_repos/index.md           | 11 ++-----
 doc/ci/docker/using_docker_images.md               | 37 ++++++++--------------
 doc/ci/examples/php.md                             | 13 +++-----
 doc/ci/git_submodules.md                           |  8 ++---
 doc/ci/pipelines/job_artifacts.md                  | 10 ++----
 doc/ci/quick_start/README.md                       | 13 +++-----
 doc/ci/runners/README.md                           | 27 ++++++----------
 doc/ci/services/docker-services.md                 |  2 ++
 doc/ci/services/postgres.md                        |  9 ++----
 doc/ci/ssh_keys/README.md                          |  4 +--
 doc/ci/triggers/README.md                          | 21 ++++--------
 doc/ci/variables/README.md                         | 18 ++---------
 doc/ci/variables/predefined_variables.md           | 10 ++----
 doc/ci/yaml/README.md                              | 37 ++++++++--------------
 15 files changed, 71 insertions(+), 153 deletions(-)

(limited to 'doc/ci')

diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
index 9aed5020f2b..3437f867cb8 100644
--- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
@@ -16,7 +16,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 
    ![Create project](img/external_repository.png)
 
-   GitLab will import the repository and enable [Pull Mirroring][pull-mirroring].
+   GitLab will import the repository and enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter).
 
 1. In GitLab create a
    [Personal Access Token](../../user/profile/personal_access_tokens.md)
@@ -151,8 +151,6 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 GitLab is now configured to mirror changes from Bitbucket, run CI/CD pipelines
 configured in `.gitlab-ci.yml` and push the status to Bitbucket.
 
-[pull-mirroring]: ../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/ci/ci_cd_for_external_repos/index.md b/doc/ci/ci_cd_for_external_repos/index.md
index 704894f51b3..cc6645b72c2 100644
--- a/doc/ci/ci_cd_for_external_repos/index.md
+++ b/doc/ci/ci_cd_for_external_repos/index.md
@@ -4,7 +4,7 @@ type: index, howto
 
 # GitLab CI/CD for external repositories **(PREMIUM)**
 
->[Introduced][ee-4642] in [GitLab Premium][eep] 10.6.
+>[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4642) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.6.
 
 GitLab CI/CD can be used with:
 
@@ -15,10 +15,10 @@ GitLab CI/CD can be used with:
 Instead of moving your entire project to GitLab, you can connect your
 external repository to get the benefits of GitLab CI/CD.
 
-Connecting an external repository will set up [repository mirroring][mirroring]
+Connecting an external repository will set up [repository mirroring](../../user/project/repository/repository_mirroring.md)
 and create a lightweight project with issues, merge requests, wiki, and
 snippets disabled. These features
-[can be re-enabled later][settings].
+[can be re-enabled later](../../user/project/settings/index.md#sharing-and-permissions).
 
 To connect to an external repository:
 
@@ -94,8 +94,3 @@ references an open Pull Request, both will contribute to the status of the Pull
 via GitHub integration. If you want to exclusively run pipelines on external pull
 requests and not on branches you can add `except: [branches]` to the job specs.
 [Read more](https://gitlab.com/gitlab-org/gitlab/issues/24089#workaround).
-
-[ee-4642]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4642
-[eep]: https://about.gitlab.com/pricing/
-[mirroring]: ../../user/project/repository/repository_mirroring.md
-[settings]: ../../user/project/settings/index.md#sharing-and-permissions
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index f56e7a161ca..b371a74bd71 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -9,7 +9,7 @@ GitLab CI/CD in conjunction with [GitLab Runner](../runners/README.md) can use
 
 Docker is an open-source project that allows you to use predefined images to
 run applications in independent "containers" that are run within a single Linux
-instance. [Docker Hub][hub] has a rich database of pre-built images that can be
+instance. [Docker Hub](https://hub.docker.com/) has a rich database of pre-built images that can be
 used to test and build your applications.
 
 When used with GitLab CI/CD, Docker runs each job in a separate and isolated
@@ -23,7 +23,7 @@ test them on a dedicated CI server.
 
 ## Register Docker Runner
 
-To use GitLab Runner with Docker you need to [register a new Runner][register]
+To use GitLab Runner with Docker you need to [register a new Runner](https://docs.gitlab.com/runner/register/)
 to use the `docker` executor.
 
 A one-line example can be seen below:
@@ -48,12 +48,12 @@ accessible during the build process.
 The `image` keyword is the name of the Docker image the Docker executor
 will run to perform the CI tasks.
 
-By default, the executor will only pull images from [Docker Hub][hub],
+By default, the executor will only pull images from [Docker Hub](https://hub.docker.com/),
 however this can be configured in the `gitlab-runner/config.toml` by setting
-the [Docker pull policy][] to allow using local images.
+the [Docker pull policy](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work) to allow using local images.
 
 For more information about images and Docker Hub, please read
-the [Docker Fundamentals][] documentation.
+the [Docker Fundamentals](https://docs.docker.com/engine/understanding-docker/) documentation.
 
 ## What is a service
 
@@ -68,7 +68,7 @@ time the project is built.
 
 You are not limited to have only database services. You can add as many
 services you need to `.gitlab-ci.yml` or manually modify `config.toml`.
-Any image found at [Docker Hub][hub] or your private Container Registry can be
+Any image found at [Docker Hub](https://hub.docker.com/) or your private Container Registry can be
 used as a service.
 
 Services inherit the same DNS servers, search domains, and additional hosts as
@@ -80,7 +80,7 @@ You can see some widely used services examples in the relevant documentation of
 ### How services are linked to the job
 
 To better understand how the container linking works, read
-[Linking containers together][linking-containers].
+[Linking containers together](https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/).
 
 To summarize, if you add `mysql` as service to your application, the image will
 then be used to create a container that is linked to the job container.
@@ -156,7 +156,7 @@ either:
 Let's say that you need a Wordpress instance to test some API integration with
 your application.
 
-You can then use for example the [tutum/wordpress][] image in your
+You can then use for example the [tutum/wordpress](https://hub.docker.com/r/tutum/wordpress/) image in your
 `.gitlab-ci.yml`:
 
 ```yaml
@@ -332,7 +332,7 @@ For example, the following two definitions are equal:
 | Setting    | Required | GitLab version | Description |
 |------------|----------|----------------| ----------- |
 | `name`     | yes, when used with any other option      | 9.4 |Full name of the image that should be used. It should contain the Registry part if needed. |
-| `entrypoint` | no     | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`][entrypoint] directive, where each shell token is a separate string in the array. |
+| `entrypoint` | no     | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
 
 ### Available settings for `services`
 
@@ -341,8 +341,8 @@ For example, the following two definitions are equal:
 | Setting    | Required | GitLab version | Description |
 |------------|----------|----------------| ----------- |
 | `name`       | yes, when used with any other option  | 9.4 | Full name of the image that should be used. It should contain the Registry part if needed. |
-| `entrypoint` | no     | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`][entrypoint] directive, where each shell token is a separate string in the array. |
-| `command`    | no       | 9.4 |Command or script that should be used as the container's command. It will be translated to arguments passed to Docker after the image's name. The syntax is similar to [`Dockerfile`'s `CMD`][cmd] directive, where each shell token is a separate string in the array. |
+| `entrypoint` | no     | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
+| `command`    | no       | 9.4 |Command or script that should be used as the container's command. It will be translated to arguments passed to Docker after the image's name. The syntax is similar to [`Dockerfile`'s `CMD`](https://docs.docker.com/engine/reference/builder/#cmd) directive, where each shell token is a separate string in the array. |
 | `alias`      | no       | 9.4 |Additional alias that can be used to access the service from the job's container. Read [Accessing the services](#accessing-the-services) for more information. |
 
 NOTE: **Note:**
@@ -420,7 +420,7 @@ services:
   command: ["/usr/bin/super-sql", "run"]
 ```
 
-As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`][cmd].
+As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`](https://docs.docker.com/engine/reference/builder/#cmd).
 
 ### Overriding the entrypoint of an image
 
@@ -449,7 +449,7 @@ you should check which one your Runner is using. Specifically:
 - If Docker 17.03 or previous versions are used, the `entrypoint` can be set to
   `/bin/sh -c`, `/bin/bash -c` or an equivalent shell available in the image.
 
-The syntax of `image:entrypoint` is similar to [Dockerfile's `ENTRYPOINT`][entrypoint].
+The syntax of `image:entrypoint` is similar to [Dockerfile's `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint).
 
 Let's assume you have a `super/sql:experimental` image with some SQL database
 inside it and you would like to use it as a base image for your job because you
@@ -836,14 +836,3 @@ docker rm -f -v build service-mysql service-postgres
 This will forcefully (`-f`) remove the `build` container, the two service
 containers as well as all volumes (`-v`) that were created with the container
 creation.
-
-[Docker Fundamentals]: https://docs.docker.com/engine/understanding-docker/
-[docker pull policy]: https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work
-[hub]: https://hub.docker.com/
-[linking-containers]: https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/
-[tutum/wordpress]: https://hub.docker.com/r/tutum/wordpress/
-[postgres-hub]: https://hub.docker.com/r/_/postgres/
-[mysql-hub]: https://hub.docker.com/r/_/mysql/
-[entrypoint]: https://docs.docker.com/engine/reference/builder/#entrypoint
-[cmd]: https://docs.docker.com/engine/reference/builder/#cmd
-[register]: https://docs.gitlab.com/runner/register/
diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md
index 04a6a4ddef2..6a6c0e8fde1 100644
--- a/doc/ci/examples/php.md
+++ b/doc/ci/examples/php.md
@@ -13,7 +13,7 @@ using the Shell executor.
 
 While it is possible to test PHP apps on any system, this would require manual
 configuration from the developer. To overcome this we will be using the
-official [PHP docker image][php-hub] that can be found in Docker Hub.
+official [PHP docker image](https://hub.docker.com/_/php) that can be found in Docker Hub.
 
 This will allow us to test PHP projects against different versions of PHP.
 However, not everything is plug 'n' play, you still need to configure some
@@ -170,12 +170,12 @@ Finally, push to GitLab and let the tests begin!
 
 ### Test against different PHP versions in Shell builds
 
-The [phpenv][] project allows you to easily manage different versions of PHP
+The [phpenv](https://github.com/phpenv/phpenv) project allows you to easily manage different versions of PHP
 each with its own config. This is especially useful when testing PHP projects
 with the Shell executor.
 
 You will have to install it on your build machine under the `gitlab-runner`
-user following [the upstream installation guide][phpenv-installation].
+user following [the upstream installation guide](https://github.com/phpenv/phpenv#installation).
 
 Using phpenv also allows to easily configure the PHP environment with:
 
@@ -279,14 +279,9 @@ gitlab-runner exec shell test:app
 
 ## Example project
 
-We have set up an [Example PHP Project][php-example-repo] for your convenience
+We have set up an [Example PHP Project](https://gitlab.com/gitlab-examples/php) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/README.md).
 
 Want to hack on it? Simply fork it, commit, and push your changes. Within a few
 moments the changes will be picked by a public runner and the job will begin.
-
-[php-hub]: https://hub.docker.com/_/php
-[phpenv]: https://github.com/phpenv/phpenv
-[phpenv-installation]: https://github.com/phpenv/phpenv#installation
-[php-example-repo]: https://gitlab.com/gitlab-examples/php
diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md
index 381c0508dea..8807e1beab8 100644
--- a/doc/ci/git_submodules.md
+++ b/doc/ci/git_submodules.md
@@ -14,11 +14,11 @@ type: reference
 > - With GitLab 8.12 onward, your permissions are used to evaluate what a CI job
 >   can access. More information about how this system works can be found in the
 >   [Jobs permissions model](../user/permissions.md#job-permissions).
-> - The HTTP(S) Git protocol [must be enabled][gitpro] in your GitLab instance.
+> - The HTTP(S) Git protocol [must be enabled](../user/admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols) in your GitLab instance.
 
 ## Configuring the `.gitmodules` file
 
-If dealing with [Git submodules][gitscm], your project will probably have a file
+If dealing with [Git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules), your project will probably have a file
 named `.gitmodules`.
 
 Let's consider the following example:
@@ -98,7 +98,3 @@ remote URL. On subsequent jobs on the same Runner, `.git/config` is cached
 and already contains a full URL for the submodule, corresponding to the previous
 job, and to **a token from a previous job**. `sync` allows to force updating
 the full URL.
-
-[gitpro]: ../user/admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols
-[gitscm]: https://git-scm.com/book/en/v2/Git-Tools-Submodules "Git submodules documentation"
-[newperms]: ../user/project/new_ci_build_permissions_model.md
diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md
index 4cc6c2aa098..d44df8defcf 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -52,12 +52,12 @@ For more examples on artifacts, follow the [artifacts reference in
 ## Browsing artifacts
 
 > - From GitLab 9.2, PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them.
-> - Introduced in [GitLab 10.1][ce-14399], HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
-> - Introduced in [GitLab 12.4][gitlab-16675], artifacts in private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled.
+> - Introduced in [GitLab 10.1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14399), HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
+> - Introduced in [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675), artifacts in private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled.
 
 After a job finishes, if you visit the job's specific page, there are three
 buttons. You can download the artifacts archive or browse its contents, whereas
-the **Keep** button appears only if you have set an [expiry date] to the
+the **Keep** button appears only if you have set an [expiry date](../yaml/README.md#artifactsexpire_in) to the
 artifacts in case you changed your mind and want to keep them.
 
 ![Job artifacts browser button](img/job_artifacts_browser_button.png)
@@ -198,10 +198,6 @@ To erase a job:
 
 In order to retrieve a job artifact of a different project, you might need to use a private token in order to [authenticate and download](../../api/jobs.md#get-job-artifacts) the artifacts.
 
-[expiry date]: ../yaml/README.md#artifactsexpire_in
-[ce-14399]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14399
-[gitlab-16675]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md
index 8ef78f899c7..a14cfcfa9ed 100644
--- a/doc/ci/quick_start/README.md
+++ b/doc/ci/quick_start/README.md
@@ -6,7 +6,7 @@ type: reference
 
 NOTE: **Note:**
 Starting from version 8.0, GitLab [Continuous Integration](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) (CI)
-is fully integrated into GitLab itself and is [enabled] by default on all
+is fully integrated into GitLab itself and is [enabled](../enable_or_disable_ci.md) by default on all
 projects.
 
 NOTE: **Note:**
@@ -75,7 +75,7 @@ Because `.gitlab-ci.yml` is in the repository and is version controlled, old
 versions still build successfully, forks can easily make use of CI, branches can
 have different pipelines and jobs, and you have a single source of truth for CI.
 You can read more about the reasons why we are using `.gitlab-ci.yml` [in our
-blog about it][blog-ci].
+blog about it](https://about.gitlab.com/blog/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/).
 
 ### Creating a simple `.gitlab-ci.yml` file
 
@@ -183,7 +183,7 @@ can be found at <https://docs.gitlab.com/runner/>.
 
 In order to have a functional Runner you need to follow two steps:
 
-1. [Install it][runner-install]
+1. [Install it](https://docs.gitlab.com/runner/install/)
 1. [Configure it](../runners/README.md#registering-a-specific-runner)
 
 Follow the links above to set up your own Runner or use a Shared Runner as
@@ -231,10 +231,5 @@ GitLab, such as **Commits** and **Merge requests**.
 
 ## Examples
 
-Visit the [examples README][examples] to see a list of examples using GitLab
+Visit the [examples README](../examples/README.md) to see a list of examples using GitLab
 CI with various languages.
-
-[runner-install]: https://docs.gitlab.com/runner/install/
-[blog-ci]: https://about.gitlab.com/blog/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
-[examples]: ../examples/README.md
-[enabled]: ../enable_or_disable_ci.md
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index 3b9e30e2b96..deefd2f0e73 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -17,7 +17,7 @@ for more information.
 
 ## Shared, specific and group Runners
 
-After [installing the Runner][install], you can either register it as shared or
+After [installing the Runner](https://docs.gitlab.com/runner/install/), you can either register it as shared or
 specific. You can only register a shared Runner if you have admin access to
 the GitLab instance. The main differences between a shared and a specific Runner
 are:
@@ -35,10 +35,10 @@ are:
   up the specific Runner with this in mind, while not having to do this for all
   Runners. For example, if you want to deploy a certain project, you can set up
   a specific Runner to have the right credentials for this. The [usage of tags](#using-tags)
-  may be useful in this case. Specific Runners process jobs using a [FIFO] queue.
+  may be useful in this case. Specific Runners process jobs using a [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) queue.
 - **Group Runners** are useful when you have multiple projects under one group
   and would like all projects to have access to a set of Runners. Group Runners
-  process jobs using a [FIFO] queue.
+  process jobs using a [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) queue.
 
 A Runner that is specific only runs for the specified project(s). A shared Runner
 can run jobs for every project that has enabled the option **Allow shared Runners**
@@ -64,7 +64,7 @@ You can only register a shared Runner if you are an admin of the GitLab instance
 
    ![Shared Runners Admin Area](img/shared_runners_admin.png)
 
-1. [Register the Runner][register]
+1. [Register the Runner](https://docs.gitlab.com/runner/register/)
 
 Shared Runners are enabled by default as of GitLab 8.2, but can be disabled
 with the **Disable shared Runners** button which is present under each project's
@@ -84,7 +84,7 @@ To create a specific Runner without having admin rights to the GitLab instance,
 visit the project you want to make the Runner work for in GitLab:
 
 1. Go to **Settings > CI/CD** to obtain the token
-1. [Register the Runner][register]
+1. [Register the Runner](https://docs.gitlab.com/runner/register/)
 
 ## Registering a group Runner
 
@@ -92,7 +92,7 @@ Creating a group Runner requires Owner permissions for the group. To create a
 group Runner visit the group you want to make the Runner work for in GitLab:
 
 1. Go to **Settings > CI/CD** to obtain the token
-1. [Register the Runner][register]
+1. [Register the Runner](https://docs.gitlab.com/runner/register/)
 
 ### Making an existing shared Runner specific
 
@@ -111,7 +111,7 @@ From now on, the shared Runner will be specific to those projects.
 
 You can configure a Runner to assign it exclusively to a project. When a
 Runner is locked this way, it can no longer be enabled for other projects.
-This setting can be enabled the first time you [register a Runner][register] and
+This setting can be enabled the first time you [register a Runner](https://docs.gitlab.com/runner/register/) and
 can be changed afterwards under each Runner's settings.
 
 To lock/unlock a Runner:
@@ -160,7 +160,7 @@ An admin can enable/disable a specific Runner for projects:
 
 You can protect Runners from revealing sensitive information.
 Whenever a Runner is protected, the Runner picks only jobs created on
-[protected branches] or [protected tags], and ignores other jobs.
+[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md), and ignores other jobs.
 
 To protect/unprotect Runners:
 
@@ -245,7 +245,7 @@ the appropriate dependencies to run Rails test suites.
 
 ### Allowing Runners with tags to pick jobs without tags
 
-When you [register a Runner][register], its default behavior is to **only pick**
+When you [register a Runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
 [tagged jobs](../yaml/README.md#tags).
 
 NOTE: **Note:**
@@ -305,7 +305,7 @@ Example 2:
 ### Setting maximum job timeout for a Runner
 
 For each Runner you can specify a _maximum job timeout_. Such timeout,
-if smaller than [project defined timeout], will take the precedence. This
+if smaller than [project defined timeout](../pipelines/settings.md#timeout), will take the precedence. This
 feature can be used to prevent Shared Runner from being appropriated
 by a project by setting a ridiculous big timeout (for example, one week).
 
@@ -416,10 +416,3 @@ You can find the IP address of a Runner for a specific project by:
 1. On the details page you should see a row for "IP Address"
 
 ![specific Runner IP address](img/specific_runner_ip_address.png)
-
-[install]: https://docs.gitlab.com/runner/install/
-[fifo]: https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)
-[register]: https://docs.gitlab.com/runner/register/
-[protected branches]: ../../user/project/protected_branches.md
-[protected tags]: ../../user/project/protected_tags.md
-[project defined timeout]: ../pipelines/settings.md#timeout
diff --git a/doc/ci/services/docker-services.md b/doc/ci/services/docker-services.md
index e5fc7a3c85f..fdd38ed4c4e 100644
--- a/doc/ci/services/docker-services.md
+++ b/doc/ci/services/docker-services.md
@@ -1,3 +1,5 @@
 ---
 redirect_to: 'README.md'
 ---
+
+This document was moved to [another location](README.md).
diff --git a/doc/ci/services/postgres.md b/doc/ci/services/postgres.md
index 4cf3e429c63..cf34c28497e 100644
--- a/doc/ci/services/postgres.md
+++ b/doc/ci/services/postgres.md
@@ -45,11 +45,11 @@ Database: nice_marmot
 If you are wondering why we used `postgres` for the `Host`, read more at
 [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].
+You can also use any other docker image available on [Docker Hub](https://hub.docker.com/_/postgres).
 For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`.
 
 The `postgres` image can accept some environment variables. For more details
-check the documentation on [Docker Hub][hub-pg].
+check the documentation on [Docker Hub](https://hub.docker.com/_/postgres).
 
 ## Use PostgreSQL with the Shell executor
 
@@ -115,12 +115,9 @@ Database: nice_marmot
 
 ## Example project
 
-We have set up an [Example PostgreSQL Project][postgres-example-repo] for your
+We have set up an [Example PostgreSQL Project](https://gitlab.com/gitlab-examples/postgres) for your
 convenience that runs on [GitLab.com](https://gitlab.com) using our publicly
 available [shared runners](../runners/README.md).
 
 Want to hack on it? Simply fork it, commit and push your changes. Within a few
 moments the changes will be picked by a public runner and the job will begin.
-
-[hub-pg]: https://hub.docker.com/_/postgres
-[postgres-example-repo]: https://gitlab.com/gitlab-examples/postgres
diff --git a/doc/ci/ssh_keys/README.md b/doc/ci/ssh_keys/README.md
index b3a97d34575..b3403cd246f 100644
--- a/doc/ci/ssh_keys/README.md
+++ b/doc/ci/ssh_keys/README.md
@@ -204,11 +204,9 @@ before_script:
 
 ## Example project
 
-We have set up an [Example SSH Project][ssh-example-repo] for your convenience
+We have set up an [Example SSH Project](https://gitlab.com/gitlab-examples/ssh-private-key/) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/README.md).
 
 Want to hack on it? Simply fork it, commit and push your changes. Within a few
 moments the changes will be picked by a public runner and the job will begin.
-
-[ssh-example-repo]: https://gitlab.com/gitlab-examples/ssh-private-key/
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
index 98d3a08977c..29deed724f9 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -29,12 +29,12 @@ to protect trigger tokens.
 
 ### CI job token
 
-You can use the `CI_JOB_TOKEN` [variable][predef] (used to authenticate
-with the [GitLab Container Registry][registry]) in the following cases.
+You can use the `CI_JOB_TOKEN` [variable](../variables/README.md#predefined-environment-variables) (used to authenticate
+with the [GitLab Container Registry](../../user/packages/container_registry/index.md)) in the following cases.
 
 #### When used with multi-project pipelines
 
-> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [introduced][ee-2017] in [GitLab Premium][ee] 9.3.
+> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.3.
 > - Use of `CI_JOB_TOKEN` for multi-project pipelines was [made available](https://gitlab.com/gitlab-org/gitlab/issues/31573) in all tiers in GitLab 12.4.
 
 This way of triggering can only be used when invoked inside `.gitlab-ci.yml`,
@@ -53,11 +53,11 @@ build_docs:
 Pipelines triggered that way also expose a special variable:
 `CI_PIPELINE_SOURCE=pipeline`.
 
-Read more about the [pipelines trigger API][trigapi].
+Read more about the [pipelines trigger API](../../api/pipeline_triggers.md).
 
 #### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
 
-> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346] in [GitLab Premium][ee] 9.5.
+> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.5.
 
 With the introduction of dependencies between different projects, one of
 them may need to access artifacts created by a previous one. This process
@@ -78,7 +78,7 @@ build_submodule:
 
 This allows you to use that for multi-project pipelines and download artifacts
 from any project to which you have access as this follows the same principles
-with the [permission model][permissions].
+with the [permission model](../../user/permissions.md#job-permissions).
 
 Read more about the [jobs API](../../api/jobs.md#download-the-artifacts-archive).
 
@@ -273,12 +273,3 @@ 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.
-
-[ee-2017]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017
-[ee-2346]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346
-[ee]: https://about.gitlab.com/pricing/
-[variables]: ../variables/README.md
-[predef]: ../variables/README.md#predefined-environment-variables
-[registry]: ../../user/packages/container_registry/index.md
-[permissions]: ../../user/permissions.md#job-permissions
-[trigapi]: ../../api/pipeline_triggers.md
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index af41d1ab958..831669b6f6b 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -221,7 +221,7 @@ All variables are set as environment variables in the build environment, and
 they are accessible with normal methods that are used to access such variables.
 In most cases `bash` or `sh` is used to execute the job script.
 
-To access environment variables, use the syntax for your Runner's [shell][shellexecutors].
+To access environment variables, use the syntax for your Runner's [shell](https://docs.gitlab.com/runner/executors/).
 
 | Shell                | Usage           |
 |----------------------|-----------------|
@@ -415,7 +415,7 @@ Click [here](where_variables_can_be_used.md) for a section that describes where
 
 Variables can be protected. Whenever a variable is
 protected, it would only be securely passed to pipelines running on the
-[protected branches] or [protected tags]. The other pipelines would not get any
+[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md). The other pipelines would not get any
 protected variables.
 
 Protected variables can be added by going to your project's
@@ -427,7 +427,7 @@ Once you set them, they will be available for all subsequent pipelines.
 ### Limiting environment scopes of environment variables
 
 You can limit the environment scope of a variable by
-[defining which environments][envs] it can be available for.
+[defining which environments](../environments.md) it can be available for.
 
 To learn more about about scoping environments, see [Scoping environments with specs](../environments.md#scoping-environments-with-specs).
 
@@ -802,15 +802,3 @@ if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
 
 ...
 ```
-
-[ce-13784]: https://gitlab.com/gitlab-org/gitlab-foss/issues/13784 "Simple protection of CI variables"
-[envs]: ../environments.md
-[protected branches]: ../../user/project/protected_branches.md
-[protected tags]: ../../user/project/protected_tags.md
-[shellexecutors]: https://docs.gitlab.com/runner/executors/
-[triggered]: ../triggers/README.md
-[trigger-job-token]: ../triggers/README.md#ci-job-token
-[gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
-[registry]: ../../user/project/container_registry.md
-[dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories
-[get-job-artifacts]:  ../../api/jobs.html#get-job-artifacts
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index 0fab965a0c0..835699359bf 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -45,8 +45,8 @@ future GitLab releases.**
 | `CI_CONFIG_PATH`                              | 9.4    | 0.5    | The path to CI config file. Defaults to `.gitlab-ci.yml`                                                                                                                                                                                                                                                                                                   |
 | `CI_DEBUG_TRACE`                              | all    | 1.7    | Whether [debug logging (tracing)](README.md#debug-logging) is enabled                                                                                                                                                                                                                                                                                      |
 | `CI_DEFAULT_BRANCH`                           | 12.4   | all    | The name of the default branch for the project.                                                                                                                                                                                                                                                                                                            |
-| `CI_DEPLOY_PASSWORD`                          | 10.8   | all    | Authentication password of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related.                                                                                                                                                                                                                                    |
-| `CI_DEPLOY_USER`                              | 10.8   | all    | Authentication username of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related.                                                                                                                                                                                                                                    |
+| `CI_DEPLOY_PASSWORD`                          | 10.8   | all    | Authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), only present if the Project has one related.                                                                                                                                                                                                                                    |
+| `CI_DEPLOY_USER`                              | 10.8   | all    | Authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), only present if the Project has one related.                                                                                                                                                                                                                                    |
 | `CI_DISPOSABLE_ENVIRONMENT`                   | all    | 10.1   | Marks that the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). If the environment is disposable, it is set to true, otherwise it is not defined at all.                                                                  |
 | `CI_ENVIRONMENT_NAME`                         | 8.15   | all    | The name of the environment for this job. Only present if [`environment:name`](../yaml/README.md#environmentname) is set.                                                                                                                                                                                                                                  |
 | `CI_ENVIRONMENT_SLUG`                         | 8.15   | all    | A simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, etc. Only present if [`environment:name`](../yaml/README.md#environmentname) is set.                                                                                                                                                                 |
@@ -61,7 +61,7 @@ future GitLab releases.**
 | `CI_JOB_MANUAL`                               | 8.12   | all    | The flag to indicate that job was manually started                                                                                                                                                                                                                                                                                                         |
 | `CI_JOB_NAME`                                 | 9.0    | 0.5    | The name of the job as defined in `.gitlab-ci.yml`                                                                                                                                                                                                                                                                                                         |
 | `CI_JOB_STAGE`                                | 9.0    | 0.5    | The name of the stage as defined in `.gitlab-ci.yml`                                                                                                                                                                                                                                                                                                       |
-| `CI_JOB_TOKEN`                                | 9.0    | 1.2    | Token used for authenticating with the [GitLab Container Registry][registry] and downloading [dependent repositories][dependent-repositories]                                                                                                                                                                                                              |
+| `CI_JOB_TOKEN`                                | 9.0    | 1.2    | Token used for authenticating with the [GitLab Container Registry](../../user/packages/container_registry/index.md) and downloading [dependent repositories](../../user/project/new_ci_build_permissions_model.md#dependent-repositories)                                                                                                                                                                                                              |
 | `CI_JOB_URL`                                  | 11.1   | 0.5    | Job details URL                                                                                                                                                                                                                                                                                                                                            |
 | `CI_MERGE_REQUEST_ASSIGNEES`                  | 11.9   | all    | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the merge request is created.                                                                                                              |
 | `CI_MERGE_REQUEST_CHANGED_PAGE_PATHS`         | 12.9   | all    | Comma-separated list of paths of changed pages in a deployed [Review App](../review_apps/index.md) for a [Merge Request](../merge_request_pipelines/index.md). A [Route Map](../review_apps/index.md#route-maps) must be configured.                                                                                 |
@@ -134,7 +134,3 @@ future GitLab releases.**
 | `GITLAB_USER_LOGIN`                           | 10.0   | all    | The login username of the user who started the job                                                                                                                                                                                                                                                                                                         |
 | `GITLAB_USER_NAME`                            | 10.0   | all    | The real name of the user who started the job                                                                                                                                                                                                                                                                                                              |
 | `RESTORE_CACHE_ATTEMPTS`                      | 8.15   | 1.9    | Number of attempts to restore the cache running a job                                                                                                                                                                                                                                                                                                      |
-
-[gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
-[registry]: ../../user/packages/container_registry/index.md
-[dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 0930185371a..85a2e91682d 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -543,7 +543,7 @@ In addition, `only` and `except` allow the use of special keywords:
 | `external`       | When using CI services other than GitLab. |
 | `pipelines`      | For multi-project triggers, created using the API with `CI_JOB_TOKEN`. |
 | `pushes`         | Pipeline is triggered by a `git push` by the user. |
-| `schedules`      | For [scheduled pipelines][schedules]. |
+| `schedules`      | For [scheduled pipelines](../pipelines/schedules.md). |
 | `triggers`       | For pipelines created using a trigger token. |
 | `web`            | For pipelines created using **Run pipeline** button in GitLab UI (under your project's **Pipelines**). |
 | `merge_requests` | When a merge request is created or updated (See [pipelines for merge requests](../merge_request_pipelines/index.md)). |
@@ -577,7 +577,7 @@ job:
 ```
 
 In this example, `job` will run only for refs that are tagged, or if a build is
-explicitly requested via an API trigger or a [Pipeline Schedule][schedules]:
+explicitly requested via an API trigger or a [Pipeline Schedule](../pipelines/schedules.md):
 
 ```yaml
 job:
@@ -739,7 +739,7 @@ The `refs` strategy can take the same values as the
 [simplified only/except configuration](#onlyexcept-basic).
 
 In the example below, the `deploy` job is going to be created only when the
-pipeline has been [scheduled][schedules] or runs for the `master` branch:
+pipeline has been [scheduled](../pipelines/schedules.md) or runs for the `master` branch:
 
 ```yaml
 deploy:
@@ -800,7 +800,7 @@ Learn more about [variables expressions](../variables/README.md#environment-vari
 
 #### `only:changes`/`except:changes`
 
-> `changes` policy [introduced][ce-19232] in GitLab 11.4.
+> `changes` policy [introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/19232) in GitLab 11.4.
 
 Using the `changes` keyword with `only` or `except` makes it possible to define if
 a job should be created based on files modified by a Git push event.
@@ -1480,7 +1480,7 @@ GitLab Runner will pick your job soon and start the job.
 
 > - Introduced in GitLab 8.9.
 > - You can read more about environments and find more examples in the
->   [documentation about environments][environment].
+>   [documentation about environments](../environments.md).
 
 `environment` is used to define that a job deploys to a specific environment.
 If `environment` is specified and no environment under that name exists, a new
@@ -1562,7 +1562,7 @@ deploy to production:
 
 #### `environment:on_stop`
 
-> - [Introduced][ce-6669] in GitLab 8.13.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6669) in GitLab 8.13.
 > - Starting with GitLab 8.14, when you have an environment that has a stop action
 >   defined, GitLab will automatically trigger a stop action when the associated
 >   branch is deleted.
@@ -1575,7 +1575,7 @@ Read the `environment:action` section for an example.
 
 #### `environment:action`
 
-> [Introduced][ce-6669] in GitLab 8.13.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6669) in GitLab 8.13.
 
 The `action` keyword is to be used in conjunction with `on_stop` and is defined
 in the job that is called to close the environment.
@@ -1682,8 +1682,8 @@ To follow progress on support for GitLab-managed clusters, see the
 
 #### Dynamic environments
 
-> - [Introduced][ce-6323] in GitLab 8.12 and GitLab Runner 1.6.
-> - The `$CI_ENVIRONMENT_SLUG` was [introduced][ce-7983] in GitLab 8.15.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6323) in GitLab 8.12 and GitLab Runner 1.6.
+> - The `$CI_ENVIRONMENT_SLUG` was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7983) in GitLab 8.15.
 > - The `name` and `url` parameters can use any of the defined CI variables,
 >   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
 >   You however cannot use variables defined under `script`.
@@ -1701,7 +1701,7 @@ deploy as review app:
 
 The `deploy as review app` job will be marked as deployment to dynamically
 create the `review/$CI_COMMIT_REF_NAME` environment, where `$CI_COMMIT_REF_NAME`
-is an [environment variable][variables] set by the Runner. The
+is an [environment variable](../variables/README.md) set by the Runner. The
 `$CI_ENVIRONMENT_SLUG` variable is based on the environment name, but suitable
 for inclusion in URLs. In this case, if the `deploy as review app` job was run
 in a branch named `pow`, this environment would be accessible with an URL like
@@ -2652,7 +2652,7 @@ Downloading artifacts from jobs that are run in [`parallel:`](#parallel) is not
 
 ### `coverage`
 
-> [Introduced][ce-7447] in GitLab 8.17.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7447) in GitLab 8.17.
 
 `coverage` allows you to configure how code coverage will be extracted from the
 job output.
@@ -2672,7 +2672,7 @@ job1:
 
 ### `retry`
 
-> - [Introduced][ce-12909] in GitLab 9.5.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909) in GitLab 9.5.
 > - [Behaviour expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
 
 `retry` allows you to configure how many times a job is going to be retried in
@@ -3613,7 +3613,7 @@ which can be set in GitLab's UI.
 
 [YAML anchors for variables](#yaml-anchors-for-variables) are available.
 
-Learn more about [variables and their priority][variables].
+Learn more about [variables and their priority](../variables/README.md).
 
 #### Git strategy
 
@@ -4202,14 +4202,3 @@ questions that you know someone might ask.
 Each scenario can be a third-level heading, e.g. `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
-
-[ce-6323]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6323
-[ce-6669]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6669
-[ce-7983]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7983
-[ce-7447]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7447
-[ce-12909]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909
-[ce-19232]: https://gitlab.com/gitlab-org/gitlab-foss/issues/19232
-[environment]: ../environments.md "CI/CD environments"
-[schedules]: ../pipelines/schedules.md "Pipelines schedules"
-[variables]: ../variables/README.md "CI/CD variables"
-[push-option]: https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt
-- 
cgit v1.2.1