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

Docs: Updated runner capitalization

See merge request gitlab-org/gitlab!42150

doc/ci/examples/artifactory_and_gitlab/index.md

@@ -77,7 +77,7 @@ is to configure the authentication data. It is a simple task, but Maven requires
 it to stay in a file called `settings.xml` that has to be in the `.m2` subdirectory
 in the user's homedir.
 
-Since you want to use GitLab Runner to automatically deploy the application, you
+Since you want to use a runner to automatically deploy the application, you
 should create the file in the project's home directory and set a command line
 parameter in `.gitlab-ci.yml` to use the custom location instead of the default one:
 
@@ -105,7 +105,7 @@ parameter in `.gitlab-ci.yml` to use the custom location instead of the default
 Now it's time we set up [GitLab CI/CD](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) to automatically build, test and deploy the dependency!
 
 GitLab CI/CD uses a file in the root of the repository, named `.gitlab-ci.yml`, to read the definitions for jobs
-that will be executed by the configured GitLab Runners. You can read more about this file in the [GitLab Documentation](../../yaml/README.md).
+that will be executed by the configured runners. You can read more about this file in the [GitLab Documentation](../../yaml/README.md).
 
 First of all, remember to set up variables for your deployment. Navigate to your project's **Settings > CI/CD > Environment variables** page
 and add the following ones (replace them with your current values, of course):
@@ -146,7 +146,7 @@ deploy:
     - master
 ```
 
-GitLab Runner will use the latest [Maven Docker image](https://hub.docker.com/_/maven/), which already contains all the tools and the dependencies you need to manage the project,
+The runner will use the latest [Maven Docker image](https://hub.docker.com/_/maven/), which already contains all the tools and the dependencies you need to manage the project,
 in order to run the jobs.
 
 Environment variables are set to instruct Maven to use the `homedir` of the repository instead of the user's home when searching for configuration and dependencies.

doc/ci/examples/deployment/README.md

@@ -117,7 +117,7 @@ We also use two secure variables:
 
 Secure Variables can added by going to your project's
 **Settings ➔ CI / CD ➔ Variables**. The variables that are defined
-in the project settings are sent along with the build script to the Runner.
+in the project settings are sent along with the build script to the runner.
 The secure variables are stored out of the repository. Never store secrets in
 your project's `.gitlab-ci.yml`. It is also important that the secret's value
 is hidden in the job log.

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -429,7 +429,7 @@ fully understand [IAM Best Practices in AWS](https://docs.aws.amazon.com/IAM/lat
 ### Deploy your game with GitLab CI/CD
 
 To deploy our build artifacts, we need to install the [AWS CLI](https://aws.amazon.com/cli/) on
-the Shared Runner. The Shared Runner also needs to be able to authenticate with your AWS
+the shared runner. The shared runner also needs to be able to authenticate with your AWS
 account to deploy the artifacts. By convention, AWS CLI will look for `AWS_ACCESS_KEY_ID`
 and `AWS_SECRET_ACCESS_KEY`. GitLab's CI gives us a way to pass the variables we
 set up in the prior section using the `variables` portion of the `deploy` job. At the end,

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -530,8 +530,8 @@ That's a lot to take in, isn't it? Let's run through it step by step.
 
 #### Image and Services
 
-[GitLab Runners](../../runners/README.md) run the script defined by `.gitlab-ci.yml`.
-The `image` keyword tells the Runners which image to use.
+[Runners](../../runners/README.md) run the script defined by `.gitlab-ci.yml`.
+The `image` keyword tells the runners which image to use.
 The `services` keyword defines additional images [that are linked to the main image](../../docker/using_docker_images.md#what-is-a-service).
 Here we use the container image we created before as our main image and also use MySQL 5.7 as a service.
 
@@ -631,7 +631,7 @@ To do that, commit and push `.gitlab-ci.yml` to the `master` branch. It will tri
 
 Here we see our **Test** and **Deploy** stages.
 The **Test** stage has the `unit_test` build running.
-click on it to see the Runner's output.
+click on it to see the runner's output.
 
 ![pipeline page](img/pipeline_page.png)
 

doc/ci/examples/php.md

@@ -26,7 +26,7 @@ As with every job, you need to create a valid `.gitlab-ci.yml` describing the
 build environment.
 
 Let's first specify the PHP image that will be used for the job process
-(you can read more about what an image means in the Runner's lingo reading
+(you can read more about what an image means in the runner's lingo reading
 about [Using Docker images](../docker/using_docker_images.md#what-is-an-image)).
 
 Start by adding the image to your `.gitlab-ci.yml`:

doc/ci/examples/test-and-deploy-python-application-to-heroku.md

@@ -71,7 +71,7 @@ Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/accoun
 For each of your environments, you'll need to create a new Heroku application.
 You can do this through the [Dashboard](https://dashboard.heroku.com/).
 
-## Create Runner
+## Create a runner
 
 First install [Docker Engine](https://docs.docker.com/installation/).
 

doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md

@@ -62,7 +62,7 @@ Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/accoun
 For each of your environments, you'll need to create a new Heroku application.
 You can do this through the [Heroku Dashboard](https://dashboard.heroku.com/).
 
-## Create Runner
+## Create a runner
 
 First install [Docker Engine](https://docs.docker.com/installation/).
 
@@ -92,6 +92,6 @@ gitlab-runner register \
   --docker-image ruby:2.6
 ```
 
-With the command above, you create a Runner that uses the [`ruby:2.6`](https://hub.docker.com/_/ruby) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database.
+With the command above, you create a runner that uses the [`ruby:2.6`](https://hub.docker.com/_/ruby) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database.
 
 To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -176,10 +176,10 @@ environment it can run. Since we will work with a single environment, we'll edit
 configuration file (`test.exs`).
 
 But, why do we need to adjust our configuration? Well, GitLab CI/CD builds and tests our code in one
-isolated virtual machine, called [Runner](../../runners/README.md), using Docker technology. In this Runner,
+isolated virtual machine, called a [runner](../../runners/README.md), using Docker technology. In this runner,
 GitLab CI/CD has access to everything our Phoenix application need to run, exactly as we have in our
 `localhost`, but we have to tell GitLab CI/CD where to create and find this database using system
-variables. This way, GitLab CI/CD will create our test database inside the Runner, just like we do
+variables. This way, GitLab CI/CD will create our test database inside the runner, just like we do
 when running our Phoenix in our `localhost`.
 
 - Open `hello_gitlab_ci/config/test.exs` on your favorite code editor
@@ -256,7 +256,7 @@ project.
 
 - The first line tells GitLab what Docker image will be used.
 
-  Remember when we learn about Runners, the isolated virtual machine where GitLab CI/CD build and test
+  Remember when we learned about runners, the isolated virtual machine where GitLab CI/CD builds and tests
   our application? This virtual machine must have all dependencies to run our application. This is
   where a Docker image is needed. The correct image will provide the entire system for us.
 
@@ -395,5 +395,5 @@ using GitLab CI/CD. The benefits to our teams will be huge!
 
 - [GitLab CI/CD introductory guide](https://about.gitlab.com/blog/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/)
 - [GitLab CI/CD full Documentation](../../README.md)
-- [GitLab Runners documentation](../../runners/README.md)
+- [GitLab Runner documentation](../../runners/README.md)
 - [Using Docker images documentation](../../docker/using_docker_images.md)

doc/ci/git_submodules.md

@@ -94,10 +94,10 @@ correctly with your CI jobs:
    whether you have recursive submodules.
 
 The rationale to set the `sync` and `update` in `before_script` is because of
-the way Git submodules work. On a fresh Runner workspace, Git will set the
+the way Git submodules work. On a fresh runner workspace, Git will set the
 submodule URL including the token in `.git/config`
 (or `.git/modules/<submodule>/config`) based on `.gitmodules` and the current
-remote URL. On subsequent jobs on the same Runner, `.git/config` is cached
+remote URL. On subsequent jobs on the same runner, `.git/config` is cached
 and already contains a full URL for the submodule, corresponding to the previous
 job, and to **a token from a previous job**. `sync` allows to force updating
 the full URL.