Docs: Updated runner capitalization

Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/233529

doc/user/clusters/applications.md

@@ -123,14 +123,14 @@ GitLab. It is used in conjunction with [GitLab
 CI/CD](../../ci/README.md), the open-source continuous integration
 service included with GitLab that coordinates the jobs.
 
-If the project is on GitLab.com, shared Runners are available
+If the project is on GitLab.com, shared runners are available
 (the first 2000 minutes are free, you can
 [buy more later](../../subscriptions/index.md#purchasing-additional-ci-minutes))
 and you do not have to deploy one if they are enough for your needs. If a
-project-specific Runner is desired, or there are no shared Runners, it is easy
+project-specific runner is desired, or there are no shared runners, it is easy
 to deploy one.
 
-Note that the deployed Runner will be set as **privileged**, which means it will essentially
+Note that the deployed runner will be set as **privileged**, which means it will essentially
 have root access to the underlying machine. This is required to build Docker images,
 so it is the default. Make sure you read the
 [security implications](../project/clusters/index.md#security-implications)
@@ -895,7 +895,7 @@ GitLab Runner is installed into the `gitlab-managed-apps` namespace of your clus
 In order for GitLab Runner to function, you **must** specify the following:
 
 - `gitlabUrl` - the GitLab server full URL (for example, `https://gitlab.example.com`) to register the Runner against.
-- `runnerRegistrationToken` - The registration token for adding new Runners to GitLab. This must be
+- `runnerRegistrationToken` - The registration token for adding new runners to GitLab. This must be
   [retrieved from your GitLab instance](../../ci/runners/README.md).
 
 These values can be specified using [CI variables](../../ci/variables/README.md):
@@ -910,7 +910,7 @@ management project. Refer to the
 available configuration options.
 
 NOTE: **Note:**
-Support for installing the Runner managed application is provided by the GitLab Runner group.
+Support for installing the GitLab Runner managed application is provided by the GitLab Runner group.
 If you run into unknown issues, please [open a new issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new) and ping at least 2 people from the [Runner group](https://about.gitlab.com/handbook/product/product-categories/#runner-group).
 
 ### Install Cilium using GitLab CI/CD
@@ -1488,7 +1488,7 @@ The applications below can be upgraded.
 
 | Application | GitLab version |
 | ----------- | -------------- |
-| Runner  | 11.8+          |
+| GitLab Runner  | 11.8+          |
 
 To upgrade an application:
 

doc/user/gitlab_com/index.md

@@ -124,16 +124,16 @@ A limit of:
 - 50 webhooks applies to groups. **(BRONZE ONLY)**
 - Payload is limited to 25MB
 
-## Shared Runners
+## Shared runners
 
 GitLab offers Linux and Windows shared runners hosted on GitLab.com for executing your pipelines.
 
 NOTE: **Note:**
-Shared Runners provided by GitLab are **not** configurable. Consider [installing your own Runner](https://docs.gitlab.com/runner/install/) if you have specific configuration needs.
+Shared runners provided by GitLab are **not** configurable. Consider [installing your own runner](https://docs.gitlab.com/runner/install/) if you have specific configuration needs.
 
-### Linux Shared Runners
+### Linux shared runners
 
-Linux Shared Runners on GitLab.com run in [autoscale mode](https://docs.gitlab.com/runner/configuration/autoscale.html) and are powered by Google Cloud Platform.
+Linux shared runners on GitLab.com run in [autoscale mode](https://docs.gitlab.com/runner/configuration/autoscale.html) and are powered by Google Cloud Platform.
 Autoscaling means reduced waiting times to spin up CI/CD jobs, and isolated VMs for each project,
 thus maximizing security. They're free to use for public open source projects and limited
 to 2000 CI minutes per month per group for private projects. More minutes
@@ -145,13 +145,13 @@ installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
 region of the VMs is US East1.
 Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
 
-The `gitlab-shared-runners-manager-X.gitlab.com` fleet of Runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They will not run untagged jobs and unlike the general fleet of shared Runners, the instances are re-used up to 40 times.
+The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They will not run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
 
-Jobs handled by the shared Runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
+Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
 **will be timed out after 3 hours**, regardless of the timeout configured in a
 project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
 
-Below are the shared Runners settings.
+Below are the shared runners settings.
 
 | Setting                               | GitLab.com                                        | Default    |
 | -----------                           | -----------------                                 | ---------- |
@@ -162,8 +162,8 @@ Below are the shared Runners settings.
 
 #### Pre-clone script
 
-Linux Shared Runners on GitLab.com provide a way to run commands in a CI
-job before the Runner attempts to run `git init` and `git fetch` to
+Linux shared runners on GitLab.com provide a way to run commands in a CI
+job before the runner attempts to run `git init` and `git fetch` to
 download a GitLab repository. The
 [`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
 can be used for:
@@ -252,27 +252,27 @@ sentry_dsn = "X"
       BucketName = "bucket-name"
 ```
 
-### Windows Shared Runners (beta)
+### Windows shared runners (beta)
 
-The Windows Shared Runners are currently in
+The Windows shared runners are currently in
 [beta](https://about.gitlab.com/handbook/product/#beta) and should not be used
 for production workloads.
 
 During the beta period, the
 [shared runner pipeline quota](../admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
-will apply for groups and projects in the same way as Linux Runners.
+will apply for groups and projects in the same way as Linux runners.
 This may change when the beta period ends, as discussed in this
 [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
 
-Windows Shared Runners on GitLab.com automatically autoscale by
+Windows shared runners on GitLab.com automatically autoscale by
 launching virtual machines on the Google Cloud Platform. This solution uses
 a new [autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md)
 developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
-Windows Shared Runners execute your CI/CD jobs on `n1-standard-2` instances with 2
+Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with 2
 vCPUs and 7.5GB RAM. You can find a full list of available Windows packages in the
 [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
 
-We want to keep iterating to get Windows Shared Runners in a stable state and
+We want to keep iterating to get Windows shared runners in a stable state and
 [generally available](https://about.gitlab.com/handbook/product/#generally-available-ga).
 You can follow our work towards this goal in the
 [related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
@@ -343,7 +343,7 @@ VMTag = "windows"
 #### Example
 
 Below is a simple `.gitlab-ci.yml` file to show how to start using the
-Windows Shared Runners:
+Windows shared runners:
 
 ```yaml
 .shared_windows_runners:
@@ -382,14 +382,14 @@ test:
   definition](https://about.gitlab.com/handbook/product/#beta).
 - The average provisioning time for a new Windows VM is 5 minutes.
   This means that you may notice slower build start times
-  on the Windows Shared Runner fleet during the beta. In a future
+  on the Windows shared runner fleet during the beta. In a future
   release we will update the autoscaler to enable
   the pre-provisioning of virtual machines. This will significantly reduce
   the time it takes to provision a VM on the Windows fleet. You can
   follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
-- The Windows Shared Runner fleet may be unavailable occasionally
+- The Windows shared runner fleet may be unavailable occasionally
   for maintenance or updates.
-- The Windows Shared Runner virtual machine instances do not use the
+- The Windows shared runner virtual machine instances do not use the
   GitLab Docker executor. This means that you will not be able to specify
   [`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
   your pipeline configuration.
@@ -401,9 +401,9 @@ test:
   installation of additional software packages needs to be repeated for
   each job in your pipeline.
 - The job may stay in a pending state for longer than the
-  Linux shared Runners.
+  Linux shared runners.
 - There is the possibility that we introduce breaking changes which will
-  require updates to pipelines that are using the Windows Shared Runner
+  require updates to pipelines that are using the Windows shared runner
   fleet.
 
 ## Sidekiq

doc/user/group/clusters/index.md

@@ -162,10 +162,10 @@ For a consolidated view of which CI [environments](../../../ci/environments/inde
 are deployed to the Kubernetes cluster, see the documentation for
 [cluster environments](../../clusters/environments.md).
 
-## Security of Runners
+## Security of runners
 
-For important information about securely configuring GitLab Runners, see
-[Security of Runners](../../project/clusters/add_remove_clusters.md#security-of-gitlab-runners)
+For important information about securely configuring runners, see
+[Security of runners](../../project/clusters/add_remove_clusters.md#security-of-runners)
 documentation for project-level clusters.
 
 ## More information

doc/user/group/settings/import_export.md

@@ -52,7 +52,7 @@ The following items are exported:
 The following items are **not** exported:
 
 - Projects
-- Runners token
+- Runner tokens
 - SAML discovery tokens
 
 NOTE: **Note:**

doc/user/group/subgroups/index.md

@@ -115,10 +115,10 @@ When you add a member to a subgroup, they inherit the membership and permission
 level from the parent group(s). This model allows access to nested groups if you
 have membership in one of its parents.
 
-Jobs for pipelines in subgroups can use [Runners](../../../ci/runners/README.md) registered to the parent group(s).
+Jobs for pipelines in subgroups can use [runners](../../../ci/runners/README.md) registered to the parent group(s).
 This means secrets configured for the parent group are available to subgroup jobs.
 
-In addition, maintainers of projects that belong to subgroups can see the details of Runners registered to parent group(s).
+In addition, maintainers of projects that belong to subgroups can see the details of runners registered to parent group(s).
 
 The group permissions for a member can be changed only by Owners, and only on
 the **Members** page of the group the member was added.

doc/user/project/clusters/add_remove_clusters.md

@@ -110,10 +110,10 @@ GitLab creates the following resources for ABAC clusters.
 | Environment namespace | `ServiceAccount`     | Uses namespace of environment               | Deploying to a cluster |
 | Environment namespace | `Secret`             | Token for environment ServiceAccount        | Deploying to a cluster |
 
-### Security of GitLab Runners
+### Security of runners
 
-GitLab Runners have the [privileged mode](https://docs.gitlab.com/runner/executors/docker.html#the-privileged-mode)
-enabled by default, which allows them to execute special commands and running
+Runners have the [privileged mode](https://docs.gitlab.com/runner/executors/docker.html#the-privileged-mode)
+enabled by default, which allows them to execute special commands and run
 Docker in Docker. This functionality is needed to run some of the
 [Auto DevOps](../../../topics/autodevops/index.md)
 jobs. This implies the containers are running in privileged mode and you should,
@@ -124,14 +124,14 @@ turn can do almost everything that the host can do. Be aware of the
 inherent security risk associated with performing `docker run` operations on
 arbitrary images as they effectively have root access.
 
-If you don't want to use GitLab Runner in privileged mode, either:
+If you don't want to use a runner in privileged mode, either:
 
-- Use shared Runners on GitLab.com. They don't have this security issue.
-- Set up your own Runners using the configuration described at
-  [Shared Runners](../../gitlab_com/index.md#shared-runners). This involves:
+- Use shared runners on GitLab.com. They don't have this security issue.
+- Set up your own runners using the configuration described at
+  [shared runners](../../gitlab_com/index.md#shared-runners). This involves:
   1. Making sure that you don't have it installed via
      [the applications](index.md#installing-applications).
-  1. Installing a Runner
+  1. Installing a runner
      [using `docker+machine`](https://docs.gitlab.com/runner/executors/docker_machine.html).
 
 ## Create new cluster

doc/user/project/clusters/securing.md

@@ -36,7 +36,7 @@ At a high level, the required steps include the following:
 Minimum requirements (depending on the GitLab Manage Application you want to install):
 
 - Your cluster is connected to GitLab (ModSecurity, Cilium, and Falco).
-- At least one GitLab Runner is installed (Cilium and Falco only).
+- At least one runner is installed (Cilium and Falco only).
 
 ### Understanding how GitLab Managed Apps are installed
 
@@ -62,7 +62,7 @@ deployment logs. The Web Application Firewall feature uses this installation met
 
 However, the next generation of GitLab Managed Apps V2 ([CI/CD-based GitLab Managed Apps](https://gitlab.com/groups/gitlab-org/-/epics/2103))
 don't use Sidekiq to deploy. All the applications are deployed using a GitLab CI/CD pipeline and
-therefore GitLab Runners.
+therefore, by runners.
 
 ```mermaid
 sequenceDiagram
@@ -91,14 +91,14 @@ the Web Application Firewall from the project or group Kubernetes page.
 Note that your project doesn't have to be hosted or deployed through GitLab. You can manage a
 cluster independent of the applications that use the cluster.
 
-## Set up a GitLab Runner
+## Set up a runner
 
-To install CI/CD-based GitLab Managed Apps, a pipeline using a GitLab Runner must be running in
-GitLab. You can [install a GitLab Runner](../../clusters/applications.md#gitlab-runner)
+To install CI/CD-based GitLab Managed Apps, a pipeline using a runner must be running in
+GitLab. You can [install a runner](../../clusters/applications.md#gitlab-runner)
 in the Kubernetes cluster added in the previous step, or use one of the shared runners provided by
 GitLab if you're using GitLab.com.
 
-With your cluster connected to GitLab and a GitLab Runner in place, you can proceed to the next
+With your cluster connected to GitLab and a runner in place, you can proceed to the next
 steps and start installing the Cilium and Falco GitLab Managed Apps to secure your applications
 hosted on this cluster.