Commit 9e439fbe authored by Marcel Amirault's avatar Marcel Amirault

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

Docs: Updated runner capitalization

See merge request gitlab-org/gitlab!42150
parents e36f62ad 4fc27b3e
......@@ -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.
......
......@@ -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.
......
......@@ -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,
......
......@@ -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)
......
......@@ -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`:
......
......@@ -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/).
......
......@@ -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.
......@@ -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)
......@@ -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.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment