Move runner variable config docs

Some runner features can be configured with variables,
but these details should be in the runner docs, not
the CI YAML ref.

doc/ci/environments/index.md

@@ -697,7 +697,7 @@ stop_review:
 ```
 
 If you can't use [Pipelines for merge requests](../merge_request_pipelines/index.md),
-setting the [`GIT_STRATEGY`](../yaml/README.md#git-strategy) to `none` is necessary in the
+setting the [`GIT_STRATEGY`](../runners/README.md#git-strategy) to `none` is necessary in the
 `stop_review` job so that the [runner](https://docs.gitlab.com/runner/) won't
 try to check out the code after the branch is deleted.
 

doc/ci/git_submodules.md

@@ -78,7 +78,7 @@ correctly with your CI jobs:
      GIT_SUBMODULE_STRATEGY: recursive
    ```
 
-   See the [`.gitlab-ci.yml` reference](yaml/README.md#git-submodule-strategy)
+   See the [GitLab Runner documentation](runners/README.md#git-submodule-strategy)
    for more details about `GIT_SUBMODULE_STRATEGY`.
 
 1. If you are using an older version of `gitlab-runner`, then use

doc/ci/large_repositories/index.md

@@ -78,7 +78,7 @@ done by GitLab, requiring you to do them.
 
 > Introduced in GitLab Runner 11.10.
 
-[`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) allows you to
+[`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) allows you to
 control where you clone your sources. This can have implications if you
 heavily use big repositories with fork workflow.
 
@@ -90,7 +90,7 @@ In such cases, ideally you want to make the GitLab Runner executor be used only
 for the given project and not shared across different projects to make this
 process more efficient.
 
-The [`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) has to be
+The [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) has to be
 within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path
 from disk.
 
@@ -98,12 +98,12 @@ from disk.
 
 > Introduced in GitLab Runner 11.10.
 
-[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags) allows you to control
+[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) allows you to control
 whether or not you require the `git clean` command to be executed for each CI
 job. By default, GitLab ensures that you have your worktree on the given SHA,
 and that your repository is clean.
 
-[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags) is disabled when set
+[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) is disabled when set
 to `none`. On very big repositories, this might be desired because `git
 clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
 -e .build/` (for example) allows you to control and disable removal of some
@@ -112,7 +112,7 @@ the incremental builds. This has the biggest effect if you re-use existing
 machines and have an existing worktree that you can re-use for builds.
 
 For exact parameters accepted by
-[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
+[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags), see the documentation
 for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
 are dependent on Git version.
 
@@ -120,14 +120,14 @@ are dependent on Git version.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
 
-[`GIT_FETCH_EXTRA_FLAGS`](../yaml/README.md#git-fetch-extra-flags) allows you
+[`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags) allows you
 to modify `git fetch` behavior by passing extra flags.
 
 For example, if your project contains a large number of tags that your CI jobs don't rely on,
 you could add [`--no-tags`](https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---no-tags)
 to the extra flags to make your fetches faster and more compact.
 
-See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../yaml/README.md#git-fetch-extra-flags)
+See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/README.md#git-fetch-extra-flags)
 for more information.
 
 ## Fork-based workflow

doc/ci/pipelines/settings.md

@@ -29,7 +29,7 @@ There are two options. Using:
 - `git fetch`, which is faster as it re-uses the local working copy (falling
   back to clone if it doesn't exist).
 
-The default Git strategy can be overridden by the [GIT_STRATEGY variable](../yaml/README.md#git-strategy)
+The default Git strategy can be overridden by the [GIT_STRATEGY variable](../runners/README.md#git-strategy)
 in `.gitlab-ci.yml`.
 
 ## Git shallow clone

doc/user/application_security/container_scanning/index.md

@@ -415,7 +415,7 @@ automatically generates.
 To enable remediation support, the scanning tool _must_ have access to the `Dockerfile` specified by
 the [`DOCKERFILE_PATH`](#available-variables) environment variable. To ensure that the scanning tool
 has access to this
-file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/yaml/README.md#git-strategy) in
+file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/README.md#git-strategy) in
 your `.gitlab-ci.yml` file by following the instructions described in this document's
 [overriding the container scanning template](#overriding-the-container-scanning-template) section.
 

doc/user/application_security/dast/index.md

@@ -603,7 +603,7 @@ variables:
 ### Cloning the project's repository
 
 The DAST job does not require the project's repository to be present when running, so by default
-[`GIT_STRATEGY`](../../../ci/yaml/README.md#git-strategy) is set to `none`.
+[`GIT_STRATEGY`](../../../ci/runners/README.md#git-strategy) is set to `none`.
 
 ### Debugging DAST jobs