Merge branch 'selhorn-runner-10' into 'master'

Docs: Updated runner capitalization

See merge request gitlab-org/gitlab!42175

doc/ci/merge_request_pipelines/index.md

@@ -179,7 +179,7 @@ coming from a fork:
 
 Sometimes parent project members want the pipeline to run in the parent
 project. This could be to ensure that the post-merge pipeline passes in the parent project.
-For example, a fork project could try to use a corrupted Runner that doesn't execute
+For example, a fork project could try to use a corrupted runner that doesn't execute
 test scripts properly, but reports a passed pipeline. Reviewers in the parent project
 could mistakenly trust the merge request because it passed a faked pipeline.
 

doc/ci/multi_project_pipelines.md

@@ -124,7 +124,7 @@ gets created. If you want to display the downstream pipeline's status instead, s
 
 NOTE: **Note:**
 Bridge jobs do not support every configuration entry that a user can use
-in the case of regular jobs. Bridge jobs will not be picked by a Runner,
+in the case of regular jobs. Bridge jobs will not be picked by a runner,
 so there is no point in adding support for `script`, for example. If a user
 tries to use unsupported configuration syntax, YAML validation will fail upon
 pipeline creation.

doc/ci/review_apps/index.md

@@ -46,8 +46,8 @@ In this example, a branch was:
 
 After adding Review Apps to your workflow, you follow the branched Git flow. That is:
 
-1. Push a branch and let the Runner deploy the Review App based on the `script` definition of the dynamic environment job.
-1. Wait for the Runner to build and deploy your web application.
+1. Push a branch and let the runner deploy the Review App based on the `script` definition of the dynamic environment job.
+1. Wait for the runner to build and deploy your web application.
 1. Click on the link provided in the merge request related to the branch to see the changes live.
 
 ## Configuring Review Apps
@@ -57,7 +57,7 @@ Review Apps are built on [dynamic environments](../environments/index.md#configu
 The process of configuring Review Apps is as follows:
 
 1. Set up the infrastructure to host and deploy the Review Apps (check the [examples](#review-apps-examples) below).
-1. [Install](https://docs.gitlab.com/runner/install/) and [configure](https://docs.gitlab.com/runner/commands/) a Runner to do deployment.
+1. [Install](https://docs.gitlab.com/runner/install/) and [configure](https://docs.gitlab.com/runner/commands/) a runner to do deployment.
 1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI environment variable](../variables/README.md) `${CI_COMMIT_REF_NAME}`
    to create dynamic environments and restrict it to run only on branches.
    Alternatively, you can get a YML template for this job by [enabling review apps](#enable-review-apps-button) for your project.

doc/topics/autodevops/quick_start_guide.md

@@ -8,7 +8,7 @@ to create a Kubernetes cluster manually using the Google Cloud Platform console.
 You will create and deploy a simple application that you create from a GitLab template.
 
 These instructions will also work for a self-managed GitLab instance; you'll just
-need to ensure your own [Runners are configured](../../ci/runners/README.md) and
+need to ensure your own [runners are configured](../../ci/runners/README.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
 ## Configure your Google account
@@ -110,7 +110,7 @@ In this guide, we will install Ingress and Prometheus:
 
 NOTE: **Note:**
 We won't install GitLab Runner in this quick start guide, as this guide uses the
-shared Runners provided by GitLab.com.
+shared runners provided by GitLab.com.
 
 To install the applications:
 

doc/topics/autodevops/requirements.md

@@ -48,21 +48,21 @@ To make full use of Auto DevOps with Kubernetes, you need:
 
 - **GitLab Runner** (for all stages)
 
-  Your Runner must be configured to run Docker, usually with either the
+  Your runner must be configured to run Docker, usually with either the
   [Docker](https://docs.gitlab.com/runner/executors/docker.html)
   or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with
   [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
-  The Runners don't need to be installed in the Kubernetes cluster, but the
+  The runners don't need to be installed in the Kubernetes cluster, but the
   Kubernetes executor is easy to use and automatically autoscales.
-  You can configure Docker-based Runners to autoscale as well, using
+  You can configure Docker-based runners to autoscale as well, using
   [Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
 
   If you've configured GitLab's Kubernetes integration in the first step, you
   can deploy it to your cluster by installing the
   [GitLab-managed app for GitLab Runner](../../user/clusters/applications.md#gitlab-runner).
 
-  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/README.md#shared-runners)
+  for the entire GitLab instance, or [specific runners](../../ci/runners/README.md#specific-runners)
   that are assigned to specific projects (the default if you've installed the
   GitLab Runner managed application).
 

doc/topics/offline/quick_start_guide.md

@@ -86,7 +86,7 @@ sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/docker/certs.d/my-host.interna
 ```
 
 Provide your GitLab Runner (to be installed next) with your certs by
-[following the steps for using trusted certificates with your Runner](https://docs.gitlab.com/runner/install/docker.html#installing-trusted-ssl-server-certificates):
+[following the steps for using trusted certificates with your runner](https://docs.gitlab.com/runner/install/docker.html#installing-trusted-ssl-server-certificates):
 
 ```shell
 sudo mkdir -p /etc/gitlab-runner/certs
@@ -97,7 +97,7 @@ sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/gitlab-runner/certs/ca.crt
 ## Enabling GitLab Runner
 
 [Following a similar process to the steps for installing our GitLab Runner as a
-Docker service](https://docs.gitlab.com/runner/install/docker.html#docker-image-installation), we must first register our Runner:
+Docker service](https://docs.gitlab.com/runner/install/docker.html#docker-image-installation), we must first register our runner:
 
 ```shell
 $ sudo docker run --rm -it -v /etc/gitlab-runner:/etc/gitlab-runner gitlab/gitlab-runner register
@@ -128,7 +128,7 @@ Make the following changes to `/etc/gitlab-runner/config.toml`:
 - Add Docker socket to volumes `volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]`
 - Add `pull_policy = "if-not-present"` to the executor configuration
 
-Now we can start our Runner:
+Now we can start our runner:
 
 ```shell
 sudo docker run -d --restart always --name gitlab-runner -v /etc/gitlab-runner:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest

doc/topics/web_application_firewall/quick_start_guide.md

@@ -14,7 +14,7 @@ to create a Kubernetes cluster manually using the Google Cloud Platform console.
 We will create and deploy a simple application that we create from a GitLab template.
 
 These instructions will also work for a self-managed GitLab instance. However, you will
-need to ensure your own [Runners are configured](../../ci/runners/README.md) and
+need to ensure your own [runners are configured](../../ci/runners/README.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
 **Note**: GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#ingress),
@@ -118,7 +118,7 @@ filled in the domain, click **Save changes**.
 
 Prometheus should also be installed. It is an open-source monitoring and
 alerting system that we will use to supervise the deployed application.
-We will not install GitLab Runners as we will use the shared Runners that
+We will not install GitLab Runner as we will use the shared runners that
 GitLab.com provides.
 
 ## Enabling Auto DevOps (optional)

doc/user/admin_area/index.md

@@ -20,7 +20,7 @@ The Admin Area is made up of the following sections:
 
 | Section                                        | Description                                                                                                                                                                                                                                                                              |
 |:-----------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **{overview}** [Overview](#overview-section)   | View your GitLab [Dashboard](#admin-dashboard), and administer [projects](#administering-projects), [users](#administering-users), [groups](#administering-groups), [jobs](#administering-jobs), [Runners](#administering-runners), and [Gitaly servers](#administering-gitaly-servers). |
+| **{overview}** [Overview](#overview-section)   | View your GitLab [Dashboard](#admin-dashboard), and administer [projects](#administering-projects), [users](#administering-users), [groups](#administering-groups), [jobs](#administering-jobs), [runners](#administering-runners), and [Gitaly servers](#administering-gitaly-servers). |
 | **{monitor}** Monitoring                       | View GitLab [system information](#system-info), and information on [background jobs](#background-jobs), [logs](#logs), [health checks](monitoring/health_check.md), [requests profiles](#requests-profiles), and [audit logs](#audit-log).                                  |
 | **{messages}** Messages                        | Send and manage [broadcast messages](broadcast_messages.md) for your users.                                                                                                                                                                                                              |
 | **{hook}** System Hooks                        | Configure [system hooks](../../system_hooks/system_hooks.md) for many events.                                                                                                                                                                                                            |
@@ -196,51 +196,51 @@ For each job, the following details are listed:
 | Timing   | Duration of the job, and how long ago the job completed.                |
 | Coverage | Percentage of tests coverage.                                           |
 
-### Administering Runners
+### Administering runners
 
-You can administer all Runners in the GitLab instance from the Admin Area's **Runners** page. See
-[GitLab Runner](https://docs.gitlab.com/runner/) for more information on Runner itself.
+You can administer all runners in the GitLab instance from the Admin Area's **Runners** page. See
+[GitLab Runner](https://docs.gitlab.com/runner/) for more information.
 
 To access the **Runners** page, go to **Admin Area > Overview > Runners**.
 
 The **Runners** page features:
 
-- A description of Runners, and their possible states.
-- Instructions on installing a Runner.
-- A list of all registered Runners.
+- A description of runners and their possible states.
+- Instructions on installing a runner.
+- A list of all registered runners.
 
 Runners are listed in descending order by the date they were created, by default. You can change
 the sort order to *Last Contacted* from the dropdown beside the search field.
 
-To search Runners' descriptions:
+To search runners' descriptions:
 
-1. In the **Search or filter results...** field, type the description of the Runner you want to
+1. In the **Search or filter results...** field, type the description of the runner you want to
    find.
 1. Press Enter.
 
-You can also filter Runners by status, type, and tag. To filter:
+You can also filter runners by status, type, and tag. To filter:
 
 1. Click in the **Search or filter results...** field.
 1. Select **status:**, **type:**, or **tag:**.
 1. Select or enter your search criteria.
 
-![Attributes of a Runner, with the **Search or filter results...** field active](img/index_runners_search_or_filter.png)
+![Attributes of a runner, with the **Search or filter results...** field active](img/index_runners_search_or_filter.png)
 
-For each Runner, the following attributes are listed:
+For each runner, the following attributes are listed:
 
 | Attribute    | Description |
 | ------------ | ----------- |
 | Type         | One or more of the following states: shared, group, specific, locked, or paused |
-| Runner token | Token used to identify the Runner, and which the Runner uses to communicate with the GitLab instance |
-| Description  | Description given to the Runner when it was created |
+| Runner token | Token used to identify the runner, and which the runner uses to communicate with the GitLab instance |
+| Description  | Description given to the runner when it was created |
 | Version      | GitLab Runner version |
-| IP address   | IP address of the host on which the Runner is registered |
-| Projects     | Projects to which the Runner is assigned |
-| Jobs         | Total of jobs run by the Runner |
-| Tags         | Tags associated with the Runner |
-| Last contact | Timestamp indicating when the GitLab instance last contacted the Runner |
+| IP address   | IP address of the host on which the runner is registered |
+| Projects     | Projects to which the runner is assigned |
+| Jobs         | Total of jobs run by the runner |
+| Tags         | Tags associated with the runner |
+| Last contact | Timestamp indicating when the GitLab instance last contacted the runner |
 
-You can also edit, pause, or remove each Runner.
+You can also edit, pause, or remove each runner.
 
 ### Administering Gitaly servers
 

doc/user/admin_area/settings/continuous_integration.md

@@ -7,7 +7,7 @@ type: reference
 
 # Continuous Integration and Deployment Admin settings **(CORE ONLY)**
 
-In this area, you will find settings for Auto DevOps, Runners, and job artifacts.
+In this area, you will find settings for Auto DevOps, runners, and job artifacts.
 You can find it in the **Admin Area > Settings > CI/CD**.
 
 ![Admin Area settings button](../img/admin_area_settings_button.png)
@@ -86,13 +86,13 @@ be updated for artifacts created before this setting was changed.
 The administrator may need to manually search for and expire previously-created
 artifacts, as described in the [troubleshooting documentation](../../../administration/troubleshooting/gitlab_rails_cheat_sheet.md#remove-artifacts-more-than-a-week-old).
 
-## Shared Runners pipeline minutes quota **(STARTER ONLY)**
+## Shared runners pipeline minutes quota **(STARTER ONLY)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1078) in GitLab Starter 8.16.
 
-If you have enabled shared Runners for your GitLab instance, you can limit their
+If you have enabled shared runners for your GitLab instance, you can limit their
 usage by setting a maximum number of pipeline minutes that a group can use on
-shared Runners per month. Setting this to `0` (default value) will grant
+shared runners per month. Setting this to `0` (default value) will grant
 unlimited pipeline minutes. While build limits are stored as minutes, the
 counting is done in seconds. Usage resets on the first day of each month.
 On GitLab.com, the quota is calculated based on your
@@ -116,7 +116,7 @@ also change each group's pipeline minutes quota to override the global value.
 1. Click **Save changes** for the changes to take effect.
 
 Once saved, you can see the build quota in the group admin view.
-The quota can also be viewed in the project admin view if shared Runners
+The quota can also be viewed in the project admin view if shared runners
 are enabled.
 
 ![Project admin information](img/admin_project_quota_view.png)

doc/user/permissions.md

@@ -135,7 +135,7 @@ The following table depicts the various user permission levels in a project.
 | Share (invite) projects with groups               |         |            |             | ✓ (*8*)  | ✓ (*8*)|
 | Add deploy keys to project                        |         |            |             | ✓        | ✓      |
 | Configure project hooks                           |         |            |             | ✓        | ✓      |
-| Manage Runners                                    |         |            |             | ✓        | ✓      |
+| Manage runners                                    |         |            |             | ✓        | ✓      |
 | Manage job triggers                               |         |            |             | ✓        | ✓      |
 | Manage CI/CD variables                            |         |            |             | ✓        | ✓      |
 | Manage GitLab Pages                               |         |            |             | ✓        | ✓      |