Rename builds to jobs in docs

[ci skip]

4 files changed, 13 insertions, 13 deletions

diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md
index 7d91ce6710f..d28aa282825 100644
--- a/doc/ci/examples/deployment/README.md
+++ b/doc/ci/examples/deployment/README.md
@@ -91,7 +91,7 @@ Secure Variables can added by going to `Project > Variables > Add Variable`.
 **This feature requires `gitlab-runner` with version equal or greater than 0.4.0.**
 The variables that are defined 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 projects' .gitlab-ci.yml.
-It is also important that secret's value is hidden in the build log.
+It is also important that secret's value is hidden in the job log.
 
 You access added variable by prefixing it's name with `$` (on non-Windows runners) or `%` (for Windows Batch runners):
 1. `$SECRET_VARIABLE` - use it for non-Windows runners
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 5334a73e1f5..8b0d8a003fd 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -65,7 +65,7 @@ In order, this means that:
 1. We check if the `ssh-agent` is available and we install it if it's not;
 2. We create the `~/.ssh` folder;
 3. We make sure we're running bash;
-4. We disable host checking (we don't ask for user accept when we first connect to a server; and since every build will equal a first connect, we kind of need this)
+4. We disable host checking (we don't ask for user accept when we first connect to a server; and since every job will equal a first connect, we kind of need this)
 
 And this is basically all you need in the `before_script` section.
 
@@ -153,4 +153,4 @@ stage_deploy:
     - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/_tmp
     - ssh -p22 server_user@server_host "mv htdocs/wp-content/themes/live htdocs/wp-content/themes/_old && mv htdocs/wp-content/themes/_tmp htdocs/wp-content/themes/live"
     - ssh -p22 server_user@server_host "rm -rf htdocs/wp-content/themes/_old"
-```
\ No newline at end of file
+```
diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md
index 5eeec92d976..f2dd12b67d3 100644
--- a/doc/ci/examples/php.md
+++ b/doc/ci/examples/php.md
@@ -15,10 +15,10 @@ This will allow us to test PHP projects against different versions of PHP.
 However, not everything is plug 'n' play, you still need to configure some
 things manually.
 
-As with every build, you need to create a valid `.gitlab-ci.yml` describing the
+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 build process
+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
 about [Using Docker images](../docker/using_docker_images.md#what-is-image)).
 
@@ -58,8 +58,8 @@ docker-php-ext-install pdo_mysql
 ```
 
 You might wonder what `docker-php-ext-install` is. In short, it is a script
-provided by the official php docker image that you can use to easilly install
-extensions. For more information read the the documentation at
+provided by the official php docker image that you can use to easily install
+extensions. For more information read the documentation at
 <https://hub.docker.com/r/_/php/>.
 
 Now that we created the script that contains all prerequisites for our build
@@ -142,7 +142,7 @@ Of course, `my_php.ini` must be present in the root directory of your repository
 
 ## Test PHP projects using the Shell executor
 
-The shell executor runs your builds in a terminal session on your server.
+The shell executor runs your job in a terminal session on your server.
 Thus, in order to test your projects you first need to make sure that all
 dependencies are installed.
 
@@ -280,7 +280,7 @@ that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/README.md).
 
 Want to hack on it? Simply fork it, commit and push  your changes. Within a few
-moments the changes will be picked by a public runner and the build will begin.
+moments the changes will be picked by a public runner and the job will begin.
 
 [php-hub]: https://hub.docker.com/r/_/php/
 [phpenv]: https://github.com/phpenv/phpenv
diff --git a/doc/ci/examples/test-scala-application.md b/doc/ci/examples/test-scala-application.md
index 85f8849fa99..01c13941c21 100644
--- a/doc/ci/examples/test-scala-application.md
+++ b/doc/ci/examples/test-scala-application.md
@@ -51,14 +51,14 @@ The `deploy` stage automatically deploys the project to Heroku using dpl.
 You can use other versions of Scala and SBT by defining them in
 `build.sbt`.
 
-## Display test coverage in build
+## Display test coverage in job
 
 Add the `Coverage was \[\d+.\d+\%\]` regular expression in the
-**Settings ➔ Edit Project ➔ Test coverage parsing** project setting to
+**Settings ➔ CI/CD Pipelines ➔ Coverage report** project setting to
 retrieve the [test coverage] rate from the build trace and have it
-displayed with your builds.
+displayed with your jobs.
 
-**Builds** must be enabled for this option to appear.
+**Pipelines** must be enabled for this option to appear.
 
 ## Heroku application