Merge branch 'selhorn-runner-reorg-1' into 'master'

Reorganized runner content to bring SaaS shared runners to main page

See merge request gitlab-org/gitlab!63572

app/views/shared/runners/_runner_type_alert.html.haml

@@ -5,16 +5,16 @@
       = s_('Runners|This runner is available to all groups and projects in your GitLab instance.')
     .gl-alert-body
       = s_('Runners|Shared runners are available to every project in a GitLab instance. If you want a runner to build only specific projects, restrict the project in the table below. After you restrict a runner to a project, you cannot change it back to a shared runner.')
-      = link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'shared-runners'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'shared-runners'), target: '_blank', rel: 'noopener noreferrer'
   - elsif runner.group_type?
     %h4.gl-alert-title
       = s_('Runners|This runner is available to all projects and subgroups in a group.')
     .gl-alert-body
       = s_('Runners|Use Group runners when you want all projects in a group to have access to a set of runners.')
-      = link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'group-runners'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'group-runners'), target: '_blank', rel: 'noopener noreferrer'
   - else
     %h4.gl-alert-title
       = s_('Runners|This runner is associated with specific projects.')
     .gl-alert-body
       = s_('Runners|You can set up a specific runner to be used by multiple projects but you cannot make this a shared runner.')
-      = link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'specific-runners'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'specific-runners'), target: '_blank', rel: 'noopener noreferrer'

doc/administration/index.md

@@ -172,7 +172,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [External Pipeline Validation](external_pipeline_validation.md): Enable, disable, and configure external pipeline validation.
 - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
 - [Job logs](job_logs.md): Information about the job logs.
-- [Register runners](../ci/runners/README.md#types-of-runners): Learn how to register and configure runners.
+- [Register runners](../ci/runners/runners_scope.md): Learn how to register and configure runners.
 - [Shared runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for shared runners.
 - [Enable/disable Auto DevOps](../topics/autodevops/index.md#enable-or-disable-auto-devops): Enable or disable Auto DevOps for your instance.
 

doc/ci/caching/index.md

@@ -43,9 +43,9 @@ can't link to files outside it.
 To ensure maximum availability of the cache, when you declare `cache` in your jobs,
 use one or more of the following:
 
-- [Tag your runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
+- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
   that share their cache.
-- [Use runners that are only available to a particular project](../runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
+- [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
 - [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
   different caches on each branch). For that, you can take advantage of the
   [predefined CI/CD variables](../variables/README.md#predefined-cicd-variables).

doc/ci/docker/using_docker_build.md

@@ -25,9 +25,8 @@ To enable Docker commands for your CI/CD jobs, you can use:
 If you don't want to execute a runner in privileged mode,
 but want to use `docker build`, you can also [use kaniko](using_kaniko.md).
 
-If you are using shared runners on GitLab.com, see
-[GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
-to learn more about how these runners are configured.
+If you are using shared runners on GitLab.com, 
+[learn more about how these runners are configured](../runners/README.md).
 
 ### Use the shell executor
 
@@ -91,7 +90,7 @@ The Docker image has all of the `docker` tools installed and can run
 the job script in context of the image in privileged mode.
 
 We recommend you use [Docker-in-Docker with TLS enabled](#docker-in-docker-with-tls-enabled),
-which is supported by [GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners).
+which is supported by [GitLab.com shared runners](../runners/README.md).
 
 You should always specify a specific version of the image, like `docker:19.03.12`.
 If you use a tag like `docker:stable`, you have no control over which version is used.

doc/ci/docker/using_kaniko.md

@@ -133,7 +133,7 @@ The [Least Privilege Container Builds with Kaniko on GitLab](https://www.youtube
 video is a walkthrough of the [Kaniko Docker Build](https://gitlab.com/guided-explorations/containers/kaniko-docker-build)
 Guided Exploration project pipeline. It was tested on:
 
-- [GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
+- [GitLab.com shared runners](../runners/README.md)
 - [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
 
 The example can be copied to your own group or instance for testing. More details

doc/ci/environments/deployment_safety.md

@@ -117,7 +117,7 @@ The other pipelines don't get the protected variable. You can also
 [scope variables to specific environments](../variables/where_variables_can_be_used.md#variables-with-an-environment-scope).
 We recommend that you use protected variables on protected environments to make sure that the
 secrets aren't exposed unintentionally. You can also define production secrets on the
-[runner side](../runners/README.md#prevent-runners-from-revealing-sensitive-information).
+[runner side](../runners/configure_runners.md#prevent-runners-from-revealing-sensitive-information).
 This prevents other maintainers from reading the secrets and makes sure that the runner only runs on
 protected branches.
 

doc/ci/environments/index.md

@@ -409,7 +409,7 @@ The job with [`action: stop` might not run](#the-job-with-action-stop-doesnt-run
 if it's in a later stage than the job that started the environment.
 
 If you can't use [pipelines for merge requests](../merge_request_pipelines/index.md),
-set the [`GIT_STRATEGY`](../runners/README.md#git-strategy) to `none` in the
+set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none` in the
 `stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't
 try to check out the code after the branch is deleted.
 

doc/ci/environments/protected_environments.md

@@ -215,7 +215,7 @@ configured:
   (or above) to the top-level group. They can maintain CI/CD configurations for
   the higher environments (such as production) in the group-level settings page,
   wnich includes group-level protected environments,
-  [group-level runners](../runners/README.md#group-runners),
+  [group-level runners](../runners/runners_scope.md#group-runners),
   [group-level clusters](../../user/group/clusters/index.md), etc. Those
   configurations are inherited to the child projects as read-only entries.
   This ensures that only operators can configure the organization-wide

doc/ci/git_submodules.md

@@ -53,7 +53,7 @@ To make submodules work correctly in CI/CD jobs:
 1. Make sure you use [relative URLs](#configure-the-gitmodules-file)
    for submodules located in the same GitLab server.
 1. You can set the `GIT_SUBMODULE_STRATEGY` variable to either `normal` or `recursive`
-   to tell the runner to [fetch your submodules before the job](runners/README.md#git-submodule-strategy):
+   to tell the runner to [fetch your submodules before the job](runners/configure_runners.md#git-submodule-strategy):
 
    ```yaml
    variables:

doc/ci/interactive_web_terminal/index.md

@@ -16,7 +16,7 @@ is deployed, some [security precautions](../../administration/integration/termin
 taken to protect the users.
 
 NOTE:
-[Shared runners on GitLab.com](../runners/README.md#shared-runners) do not
+[Shared runners on GitLab.com](../runners/README.md) do not
 provide an interactive web terminal. Follow [this
 issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
 adding support. For groups and projects hosted on GitLab.com, interactive web

doc/ci/large_repositories/index.md

@@ -56,7 +56,7 @@ test:
 
 > Introduced in GitLab Runner 8.9.
 
-By default, GitLab is configured to use the [`fetch` Git strategy](../runners/README.md#git-strategy),
+By default, GitLab is configured to use the [`fetch` Git strategy](../runners/configure_runners.md#git-strategy),
 which is recommended for large repositories.
 This strategy reduces the amount of data to transfer and
 does not really impact the operations that you might do on a repository from CI.
@@ -65,7 +65,7 @@ does not really impact the operations that you might do on a repository from CI.
 
 > Introduced in GitLab Runner 11.10.
 
-[`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) allows you to
+[`GIT_CLONE_PATH`](../runners/configure_runners.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.
 
@@ -77,7 +77,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`](../runners/README.md#custom-build-directories) has to be
+The [`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) has to be
 within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path
 from disk.
 
@@ -85,12 +85,12 @@ from disk.
 
 > Introduced in GitLab Runner 11.10.
 
-[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) allows you to control
+[`GIT_CLEAN_FLAGS`](../runners/configure_runners.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`](../runners/README.md#git-clean-flags) is disabled when set
+[`GIT_CLEAN_FLAGS`](../runners/configure_runners.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
@@ -99,7 +99,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`](../runners/README.md#git-clean-flags), see the documentation
+[`GIT_CLEAN_FLAGS`](../runners/configure_runners.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.
 
@@ -107,7 +107,7 @@ are dependent on Git version.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
 
-[`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags) allows you
+[`GIT_FETCH_EXTRA_FLAGS`](../runners/configure_runners.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,
@@ -119,7 +119,7 @@ tags, `--no-tags` can [make a big difference in some
 cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
 If your CI builds do not depend on Git tags it is worth trying.
 
-See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/README.md#git-fetch-extra-flags)
+See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/configure_runners.md#git-fetch-extra-flags)
 for more information.
 
 ## Fork-based workflow

doc/ci/migration/jenkins.md

@@ -128,16 +128,16 @@ agents you were using.
 
 There are some important differences in the way runners work in comparison to agents:
 
-- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/README.md#types-of-runners).
+- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/runners_scope.md).
   They self-select jobs from the scopes you've defined automatically.
-- You can also [use tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
+- You can also [use tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
   associate runners with specific jobs. For example, you can use a tag for jobs that
   require dedicated, more powerful, or specific hardware.
 - GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
   Use autoscaling to provision runners only when needed, and scale down when not needed.
   This is similar to ephemeral agents in Jenkins.
 
-If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../../user/gitlab_com/index.md#shared-runners)
+If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../runners/README.md)
 to run jobs without provisioning your own runners. We are investigating making them
 [available for self-managed instances](https://gitlab.com/groups/gitlab-org/-/epics/835)
 as well.
@@ -230,7 +230,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
 The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/README.md)
 to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
 of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users).
-We also support using [tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
+We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
 to different runners (execution agents).
 
 The `agent` section also allows you to define which Docker images should be used for execution, for which we use

doc/ci/pipelines/settings.md

@@ -35,7 +35,7 @@ There are two options. Using:
   back to clone if it doesn't exist).
   This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy).
 
-The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/README.md#git-strategy)
+The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
 in `.gitlab-ci.yml`.
 
 ## Git shallow clone
@@ -66,7 +66,7 @@ if the job surpasses the threshold, it is marked as failed.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7.
 
 Project defined timeout (either specific timeout set by user or the default
-60 minutes timeout) may be [overridden for runners](../runners/README.md#set-maximum-job-timeout-for-a-runner).
+60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
 
 ## Maximum artifacts size **(FREE SELF)**
 

doc/ci/quick_start/index.md

@@ -41,7 +41,7 @@ The job results [are displayed in a pipeline](#view-the-status-of-your-pipeline-
 In GitLab, runners are agents that run your CI/CD jobs.
 
 You might already have runners available for your project, including
-[shared runners](../runners/README.md#shared-runners), which are
+[shared runners](../runners/runners_scope.md), which are
 available to all projects in your GitLab instance.
 
 To view available runners:

doc/ci/yaml/README.md

@@ -3740,7 +3740,7 @@ Possible values for `when` are:
 - `scheduler_failure`: Retry if the scheduler failed to assign the job to a runner.
 - `data_integrity_failure`: Retry if there is a structural integrity problem detected.
 
-You can specify the number of [retry attempts for certain stages of job execution](../runners/README.md#job-stages-attempts) using variables.
+You can specify the number of [retry attempts for certain stages of job execution](../runners/configure_runners.md#job-stages-attempts) using variables.
 
 ### `timeout`
 
@@ -4801,19 +4801,19 @@ You cannot set job-level variables to be pre-filled when you run a pipeline manu
 
 You can use [CI/CD variables](../variables/README.md) to configure how the runner processes Git requests:
 
-- [`GIT_STRATEGY`](../runners/README.md#git-strategy)
-- [`GIT_SUBMODULE_STRATEGY`](../runners/README.md#git-submodule-strategy)
-- [`GIT_CHECKOUT`](../runners/README.md#git-checkout)
-- [`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags)
-- [`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags)
-- [`GIT_DEPTH`](../runners/README.md#shallow-cloning) (shallow cloning)
-- [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) (custom build directories)
-- [`TRANSFER_METER_FREQUENCY`](../runners/README.md#artifact-and-cache-settings) (artifact/cache meter update frequency)
-- [`ARTIFACT_COMPRESSION_LEVEL`](../runners/README.md#artifact-and-cache-settings) (artifact archiver compression level)
-- [`CACHE_COMPRESSION_LEVEL`](../runners/README.md#artifact-and-cache-settings) (cache archiver compression level)
+- [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy)
+- [`GIT_SUBMODULE_STRATEGY`](../runners/configure_runners.md#git-submodule-strategy)
+- [`GIT_CHECKOUT`](../runners/configure_runners.md#git-checkout)
+- [`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags)
+- [`GIT_FETCH_EXTRA_FLAGS`](../runners/configure_runners.md#git-fetch-extra-flags)
+- [`GIT_DEPTH`](../runners/configure_runners.md#shallow-cloning) (shallow cloning)
+- [`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) (custom build directories)
+- [`TRANSFER_METER_FREQUENCY`](../runners/configure_runners.md#artifact-and-cache-settings) (artifact/cache meter update frequency)
+- [`ARTIFACT_COMPRESSION_LEVEL`](../runners/configure_runners.md#artifact-and-cache-settings) (artifact archiver compression level)
+- [`CACHE_COMPRESSION_LEVEL`](../runners/configure_runners.md#artifact-and-cache-settings) (cache archiver compression level)
 
 You can also use variables to configure how many times a runner
-[attempts certain stages of job execution](../runners/README.md#job-stages-attempts).
+[attempts certain stages of job execution](../runners/configure_runners.md#job-stages-attempts).
 
 ## YAML-specific features
 

doc/development/documentation/index.md

@@ -478,7 +478,7 @@ The following GitLab features are used among others:
 - [Multi project pipelines](../../ci/multi_project_pipelines.md)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/README.md#artifacts)
-- [Specific runner](../../ci/runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
+- [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
 - [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
 
 ## Testing

doc/development/pipelines.md

@@ -583,7 +583,7 @@ several reasons:
 - It significantly reduces load on the file server, as smaller deltas mean less time spent in `git pack-objects`.
 
 The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
-[defined by GitLab.com shared runners](../user/gitlab_com/index.md#pre-clone-script).
+[defined by GitLab.com shared runners](../ci/runners/README.md#pre-clone-script).
 
 The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD variable:
 

doc/topics/autodevops/requirements.md

@@ -64,8 +64,8 @@ To make full use of Auto DevOps with Kubernetes, you need:
   You can configure Docker-based runners to autoscale as well, using
   [Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
 
-  Runners should be registered as [shared runners](../../ci/runners/README.md#shared-runners)
-  for the entire GitLab instance, or [specific runners](../../ci/runners/README.md#specific-runners)
+  Runners should be registered as [shared runners](../../ci/runners/runners_scope.md#shared-runners)
+  for the entire GitLab instance, or [specific runners](../../ci/runners/runners_scope.md#specific-runners)
   that are assigned to specific projects (the default if you've installed the
   GitLab Runner managed application).
 

doc/user/application_security/container_scanning/index.md

@@ -571,7 +571,7 @@ automatically generates.
 To enable remediation support, the scanning tool _must_ have access to the `Dockerfile` specified by
 the [`DOCKERFILE_PATH`](#available-cicd-variables) CI/CD variable. To ensure that the scanning tool
 has access to this
-file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/README.md#git-strategy) in
+file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/configure_runners.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

@@ -810,7 +810,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/runners/README.md#git-strategy) is set to `none`.
+[`GIT_STRATEGY`](../../../ci/runners/configure_runners.md#git-strategy) is set to `none`.
 
 ### Debugging DAST jobs
 

doc/user/application_security/secret_detection/index.md

@@ -177,7 +177,7 @@ is no longer supported. When overriding the template, you must use [`rules`](../
 
 #### GIT_DEPTH
 
-The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning) affects Secret Detection.
+The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning) affects Secret Detection.
 The Secret Detection analyzer relies on generating patches between commits to scan content for
 secrets. If you override the default, ensure the value is greater than 1. If the number of commits
 in an MR is greater than the GIT_DEPTH value, Secret Detection will [fail to detect secrets](#error-couldnt-run-the-gitleaks-command-exit-status-2).
@@ -399,7 +399,7 @@ ERRO[2020-11-18T18:05:52Z] object not found
 [ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks analysis failed: exit status 2
 ```
 
-To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning)
+To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning)
 to a higher value. To apply this only to the Secret Detection job, the following can be added to
 your `.gitlab-ci.yml` file:
 

doc/user/project/merge_requests/load_performance_testing.md

@@ -93,7 +93,7 @@ template that is included with GitLab.
 NOTE:
 For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
 test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
-for spec details. The [default shared GitLab.com runners](../../gitlab_com/#linux-shared-runners)
+for spec details. The [default shared GitLab.com runners](../../../ci/runners/README.md#linux-shared-runners)
 likely have insufficient specs to handle most large k6 tests.
 
 This template runs the

doc/user/project/pages/introduction.md

@@ -324,4 +324,4 @@ pages:
       - public
 ```
 
-The `FF_USE_FASTZIP` variable enables the [feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) which is needed for [`ARTIFACT_COMPRESSION_LEVEL`](../../../ci/runners/README.md#artifact-and-cache-settings).
+The `FF_USE_FASTZIP` variable enables the [feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) which is needed for [`ARTIFACT_COMPRESSION_LEVEL`](../../../ci/runners/configure_runners.md#artifact-and-cache-settings).