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

Docs: Updated runner capitalization

See merge request gitlab-org/gitlab!42257

doc/user/packages/container_registry/index.md

@@ -193,7 +193,7 @@ Before diving into the details, some things you should be aware of:
   longer, but it means you don’t get stuck without security patches for base images.
 - Doing an explicit `docker pull` before each `docker run` fetches
   the latest image that was just built. This is especially important if you are
-  using multiple Runners that cache images locally. Using the Git SHA in your
+  using multiple runners that cache images locally. Using the Git SHA in your
   image tag makes this less necessary since each job is unique and you
   shouldn't ever have a stale image. However, it's still possible to have a
   stale image if you re-build a given commit after a dependency has changed.
@@ -240,8 +240,8 @@ There are three ways to authenticate to the Container Registry via
 
 ### Container Registry examples with GitLab CI/CD
 
-If you're using Docker-in-Docker on your Runners, this is how your `.gitlab-ci.yml`
-should look similar to this:
+If you're using Docker-in-Docker on your runners, this is how your `.gitlab-ci.yml`
+should look:
 
 ```yaml
 build:

doc/user/profile/personal_access_tokens.md

@@ -85,7 +85,7 @@ token.save!
 ```
 
 This can be shortened into a single-line shell command using the
-[GitLab Rails Runner](../../administration/troubleshooting/debug.md#using-the-rails-runner):
+[Rails runner](../../administration/troubleshooting/debug.md#using-the-rails-runner):
 
 ```shell
 sudo gitlab-rails runner "token = User.find_by_username('automation-bot').personal_access_tokens.create(scopes: [:read_user, :read_repository], name: 'Automation token'); token.set_token('token-string-here123'); token.save!"
@@ -113,7 +113,7 @@ token.revoke!
 ```
 
 This can be shorted into a single-line shell command using the
-[GitLab Rails Runner](../../administration/troubleshooting/debug.md#using-the-rails-runner):
+[Rails runner](../../administration/troubleshooting/debug.md#using-the-rails-runner):
 
 ```shell
 sudo gitlab-rails runner "PersonalAccessToken.find_by_token('token-string-here123').revoke!"

doc/user/project/clusters/serverless/index.md

@@ -52,7 +52,7 @@ To run Knative on GitLab, you will need:
    The simplest way to get started is to add a cluster using GitLab's [GKE integration](../add_remove_clusters.md).
    The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
 1. **GitLab Runner:** A runner is required to run the CI jobs that will deploy serverless
-   applications or functions onto your cluster. You can install the GitLab Runner
+   applications or functions onto your cluster. You can install GitLab Runner
    onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information.
 1. **Domain Name:** Knative will provide its own load balancer using Istio. It will provide an
    external IP address or hostname for all the applications served by Knative. You will be prompted to enter a

doc/user/project/import/gemnasium.md

@@ -83,7 +83,7 @@ back to both GitLab and GitHub when completed.
 
    ![click on connected project](img/gemnasium/project_connected.png)
 
-   Your project is now mirrored on GitLab, where the Runners will be able to access
+   Your project is now mirrored on GitLab, where the runners will be able to access
    your source code and run your tests.
 
    Optional step: If you set this up on GitLab.com, make sure the project is

doc/user/project/merge_requests/code_quality.md

@@ -77,7 +77,7 @@ First, you need GitLab Runner configured:
 - For the [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
 - With enough disk space to handle generated Code Quality files. For example on the [GitLab project](https://gitlab.com/gitlab-org/gitlab) the files are approximately 7 GB.
 
-Once you set up the Runner, include the Code Quality template in your CI configuration:
+Once you set up GitLab Runner, include the Code Quality template in your CI configuration:
 
 ```yaml
 include:
@@ -136,7 +136,7 @@ This information will be automatically extracted and shown right in the merge re
 
 CAUTION: **Caution:**
 On self-managed instances, if a malicious actor compromises the Code Quality job
-definition they will be able to execute privileged Docker commands on the Runner
+definition they will be able to execute privileged Docker commands on the runner
 host. Having proper access control policies mitigates this attack vector by
 allowing access only to trusted actors.
 

doc/user/project/merge_requests/load_performance_testing.md

@@ -102,7 +102,7 @@ job.
 
 An example configuration workflow:
 
-1. Set up a GitLab Runner that can run Docker containers, such as a Runner using the
+1. Set up GitLab Runner to run Docker containers, like the
    [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
 1. Configure the default Load Performance Testing CI job in your `.gitlab-ci.yml` file.
    You need to include the template and configure it with variables:

doc/user/project/new_ci_build_permissions_model.md

@@ -83,9 +83,9 @@ We try to make sure that this token doesn't leak by:
 1. Masking the job token from job logs.
 1. Granting permissions to the job token **only** when the job is running.
 
-However, this brings a question about the Runners security. To make sure that
+However, this brings up a question about the runner's security. To make sure that
 this token doesn't leak, you should also make sure that you configure
-your Runners in the most possible secure way, by avoiding the following:
+your runners in the most possible secure way, by avoiding the following:
 
 1. Any usage of Docker's `privileged` mode is risky if the machines are re-used.
 1. Using the `shell` executor since jobs run on the same machine.
@@ -95,13 +95,13 @@ to steal the tokens of other jobs.
 
 ## Before GitLab 8.12
 
-In versions before GitLab 8.12, all CI jobs would use the CI Runner's token
+In versions before GitLab 8.12, all CI jobs would use the runner's token
 to checkout project sources.
 
-The project's Runner's token was a token that you could find under the
+The project's runner token was a token that you could find under the
 project's **Settings > Pipelines** and was limited to access only that
 project.
-It could be used for registering new specific Runners assigned to the project
+It could be used for registering new specific runners assigned to the project
 and to checkout project sources.
 It could also be used with the GitLab Container Registry for that project,
 allowing pulling and pushing Docker images from within the CI job.
@@ -123,7 +123,7 @@ Using single token had multiple security implications:
 
 - The token would be readable to anyone who had Developer access to a project
   that could run CI jobs, allowing the developer to register any specific
-  Runner for that project.
+  runner for that project.
 - The token would allow to access only the project's sources, forbidding from
   accessing any other projects.
 - The token was not expiring and was multi-purpose: used for checking out sources,
@@ -205,7 +205,7 @@ Container Registries for private projects.
 >
 > - GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
 >   for permissions. This makes the `image:` directive not work with private
->   projects automatically and it needs to be configured manually on Runner's host
+>   projects automatically and it needs to be configured manually on the GitLab Runner host
 >   with a predefined account (for example administrator's personal account with
 >   access token created explicitly for this purpose). This issue is resolved with
 >   latest changes in GitLab Runner 1.8 which receives GitLab credentials with

doc/user/project/pages/getting_started/pages_from_scratch.md

@@ -7,8 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Create a GitLab Pages website from scratch
 
 This tutorial shows you how to create a Pages site from scratch. You will start with
-a blank project and create your own CI file, which gives instruction to the
-[GitLab Runner](https://docs.gitlab.com/runner/). When your CI/CD
+a blank project and create your own CI file, which gives instruction to
+a [runner](https://docs.gitlab.com/runner/). When your CI/CD
 [pipeline](../../../../ci/pipelines/index.md) runs, the Pages site is created.
 
 This example uses the [Jekyll](https://jekyllrb.com/) Static Site Generator (SSG).
@@ -48,7 +48,7 @@ Create three files in the root (top-level) directory.
 
 ## Choose a Docker image
 
-In this example, the Runner uses a [Docker image](../../../../ci/docker/using_docker_images.md)
+In this example, the runner uses a [Docker image](../../../../ci/docker/using_docker_images.md)
 to run scripts and deploy the site.
 
 This specific Ruby image is maintained on [DockerHub](https://hub.docker.com/_/ruby).
@@ -93,7 +93,7 @@ job:
 ```
 
 For GitLab Pages, this `job` has a specific name, called `pages`.
-This setting tells the Runner you want the job to deploy your website
+This setting tells the runner you want the job to deploy your website
 with GitLab Pages:
 
 ```yaml
@@ -122,7 +122,7 @@ pages:
 ## Specify the `public` directory for artifacts
 
 Now that Jekyll has output the files to the `public` directory,
-the Runner needs to know where to get them. The artifacts are stored
+the runner needs to know where to get them. The artifacts are stored
 in the `public` directory:
 
 ```yaml

doc/user/project/pages/introduction.md

@@ -34,7 +34,7 @@ If you are using [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlabcom) to hos
 - The domain name for GitLab Pages on GitLab.com is `gitlab.io`.
 - Custom domains and TLS support are enabled.
 - Shared runners are enabled by default, provided for free and can be used to
-  build your website. If you want you can still bring your own Runner.
+  build your website. If you want you can still bring your own runner.
 
 ## Example projects