Rename builds to jobs in docs

[ci skip]

Rename builds to jobs in docs
[ci skip]
334a4093 · Achilleas Pipinellis · 68be6738 · 334a4093 · 334a4093 · 334a4093
Commit 334a4093 authored Feb 13, 2017 by Achilleas Pipinellis
63 changed files
--- a/doc/administration/build_artifacts.md
+++ b/doc/administration/build_artifacts.md
-# Build artifacts administration
+This document was moved to [jobs_artifacts](jobs_artifacts.md).
->**Notes:**
->- Introduced in GitLab 8.2 and GitLab Runner 0.7.0.
->- Starting from GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
-   changed to `ZIP`.
->- This is the administration documentation. For the user guide see
-   [user/project/builds/artifacts.md](../user/project/builds/artifacts.md).
-Artifacts is a list of files and directories which are attached to a build
-after it completes successfully. This feature is enabled by default in all
-GitLab installations. Keep reading if you want to know how to disable it.
-## Disabling build artifacts
-To disable artifacts site-wide, follow the steps below.
---
-**In Omnibus installations:**
-1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
-    ```ruby
-    gitlab_rails['artifacts_enabled'] = false
-    ```
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
---
-**In installations from source:**
-1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
-    ```yaml
-    artifacts:
-      enabled: false
-    ```
-1. Save the file and [restart GitLab][] for the changes to take effect.
-## Storing build artifacts
-After a successful build, GitLab Runner uploads an archive containing the build
-artifacts to GitLab.
-To change the location where the artifacts are stored, follow the steps below.
---
-**In Omnibus installations:**
-_The artifacts are stored by default in
-`/var/opt/gitlab/gitlab-rails/shared/artifacts`._
-1. To change the storage path for example to `/mnt/storage/artifacts`, edit
-   `/etc/gitlab/gitlab.rb` and add the following line:
-    ```ruby
-    gitlab_rails['artifacts_path'] = "/mnt/storage/artifacts"
-    ```
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
---
-**In installations from source:**
-_The artifacts are stored by default in
-`/home/git/gitlab/shared/artifacts`._
-1. To change the storage path for example to `/mnt/storage/artifacts`, edit
-   `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
-    ```yaml
-    artifacts:
-      enabled: true
-      path: /mnt/storage/artifacts
-    ```
-1. Save the file and [restart GitLab][] for the changes to take effect.
-## Set the maximum file size of the artifacts
-Provided the artifacts are enabled, you can change the maximum file size of the
-artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
-[reconfigure gitlab]: restart_gitlab.md "How to restart GitLab"
-[restart gitlab]: restart_gitlab.md "How to restart GitLab"
-## Storage statistics
-You can see the total storage used for build artifacts on groups and projects
-in the administration area, as well as through the [groups](../api/groups.md)
-and [projects APIs](../api/projects.md).
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
+# Jobs artifacts administration
+>**Notes:**
+>- Introduced in GitLab 8.2 and GitLab Runner 0.7.0.
+>- Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
+   changed to `ZIP`.
+>- Starting with GitLab 8.17, builds are renamed to jobs.
+>- This is the administration documentation. For the user guide see
+   [pipelines/job_artifacts](../user/project/pipelines/job_artifacts.md).
+Artifacts is a list of files and directories which are attached to a job
+after it completes successfully. This feature is enabled by default in all
+GitLab installations. Keep reading if you want to know how to disable it.
+## Disabling job artifacts
+To disable artifacts site-wide, follow the steps below.
+---
+**In Omnibus installations:**
+1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
+    ```ruby
+    gitlab_rails['artifacts_enabled'] = false
+    ```
+1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+---
+**In installations from source:**
+1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
+    ```yaml
+    artifacts:
+      enabled: false
+    ```
+1. Save the file and [restart GitLab][] for the changes to take effect.
+## Storing job artifacts
+After a successful job, GitLab Runner uploads an archive containing the job
+artifacts to GitLab.
+To change the location where the artifacts are stored, follow the steps below.
+---
+**In Omnibus installations:**
+_The artifacts are stored by default in
+`/var/opt/gitlab/gitlab-rails/shared/artifacts`._
+1. To change the storage path for example to `/mnt/storage/artifacts`, edit
+   `/etc/gitlab/gitlab.rb` and add the following line:
+    ```ruby
+    gitlab_rails['artifacts_path'] = "/mnt/storage/artifacts"
+    ```
+1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+---
+**In installations from source:**
+_The artifacts are stored by default in
+`/home/git/gitlab/shared/artifacts`._
+1. To change the storage path for example to `/mnt/storage/artifacts`, edit
+   `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
+    ```yaml
+    artifacts:
+      enabled: true
+      path: /mnt/storage/artifacts
+    ```
+1. Save the file and [restart GitLab][] for the changes to take effect.
+## Set the maximum file size of the artifacts
+Provided the artifacts are enabled, you can change the maximum file size of the
+artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
+## Storage statistics
+You can see the total storage used for job artifacts on groups and projects
+in the administration area, as well as through the [groups](../api/groups.md)
+and [projects APIs](../api/projects.md).
+## Implementation details
+When GitLab receives an artifacts archive, an archive metadata file is also
+generated. This metadata file describes all the entries that are located in the
+artifacts archive itself. The metadata file is in a binary format, with
+additional GZIP compression.
+GitLab does not extract the artifacts archive in order to save space, memory
+and disk I/O. It instead inspects the metadata file which contains all the
+relevant information. This is especially important when there is a lot of
+artifacts, or an archive is a very large file.
+When clicking on a specific file, [GitLab Workhorse] extracts it
+from the archive and the download begins. This implementation saves space,
+memory and disk I/O.
+[reconfigure gitlab]: restart_gitlab.md "How to restart GitLab"
+[restart gitlab]: restart_gitlab.md "How to restart GitLab"
+[gitlab workhorse]: https://gitlab.com/gitlab-org/gitlab-workhorse "GitLab Workhorse repository"
--- a/doc/ci/README.md
+++ b/doc/ci/README.md
@@ -2,22 +2,22 @@
 ## CI User documentation
- [Get started with GitLab CI](quick_start/README.md)
+- [Getting started with GitLab CI](quick_start/README.md)
 - [CI examples for various languages](examples/README.md)
 - [Learn how to enable or disable GitLab CI](enable_or_disable_ci.md)
- [Pipelines and builds](pipelines.md)
+- [Pipelines and jobs](pipelines.md)
 - [Environments and deployments](environments.md)
 - [Learn how `.gitlab-ci.yml` works](yaml/README.md)
- [Configure a Runner, the application that runs your builds](runners/README.md)
+- [Configure a Runner, the application that runs your jobs](runners/README.md)
 - [Use Docker images with GitLab Runner](docker/using_docker_images.md)
 - [Use CI to build Docker images](docker/using_docker_build.md)
 - [CI Variables](variables/README.md) - Learn how to use variables defined in
  your `.gitlab-ci.yml` or secured ones defined in your project's settings
 - [Use SSH keys in your build environment](ssh_keys/README.md)
- [Trigger builds through the API](triggers/README.md)
+- [Trigger jobs through the API](triggers/README.md)
- [Build artifacts](../user/project/builds/artifacts.md)
+- [Job artifacts](../user/project/pipelines/job_artifacts.md)
 - [User permissions](../user/permissions.md#gitlab-ci)
- [Build permissions](../user/permissions.md#build-permissions)
+- [Jobs permissions](../user/permissions.md#jobs-permissions)
 - [API](../api/ci/README.md)
 - [CI services (linked docker containers)](services/README.md)
 - [CI/CD pipelines settings](../user/project/pipelines/settings.md)
@@ -27,6 +27,6 @@
 ## Breaking changes
- [New CI build permissions model](../user/project/new_ci_build_permissions_model.md)
+- [New CI job permissions model](../user/project/new_ci_build_permissions_model.md)
-  Read about what changed in GitLab 8.12 and how that affects your builds.
+  Read about what changed in GitLab 8.12 and how that affects your jobs.
-  There's a new way to access your Git submodules and LFS objects in builds.
+  There's a new way to access your Git submodules and LFS objects in jobs.
--- a/doc/ci/build_artifacts/README.md
+++ b/doc/ci/build_artifacts/README.md
-This document was moved to:
+This document was moved to [user/project/job_artifacts.md](../../user/project/job_artifacts.md).
- [user/project/builds/artifacts.md](../../user/project/builds/artifacts.md) - user guide
- [administration/build_artifacts.md](../../administration/build_artifacts.md) - administrator guide
--- a/doc/ci/docker/README.md
+++ b/doc/ci/docker/README.md
 # Docker integration
-+ [Using Docker Images](using_docker_images.md)
+- [Using Docker Images](using_docker_images.md)
-+ [Using Docker Build](using_docker_build.md)
+- [Using Docker Build](using_docker_build.md)
\ No newline at end of file
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -12,6 +12,7 @@ One of the new trends in Continuous Integration/Deployment is to:
 1. deploy to a server from the pushed image.
 It's also useful when your application already has the `Dockerfile` that can be used to create and test an image:
 ```bash
 $ docker build -t my-image dockerfiles/
 $ docker run my-docker-image /script/to/run/tests
@@ -19,23 +20,23 @@ $ docker tag my-image my-registry:5000/my-image
 $ docker push my-registry:5000/my-image
 ```
-This requires special configuration of GitLab Runner to enable `docker` support during builds.
+This requires special configuration of GitLab Runner to enable `docker` support during jobs.
 ## Runner Configuration
-There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs.
+There are three methods to enable the use of `docker build` and `docker run` during jobs; each with their own tradeoffs.
 ### Use shell executor
 The simplest approach is to install GitLab Runner in `shell` execution mode.
-GitLab Runner then executes build scripts as the `gitlab-runner` user.
+GitLab Runner then executes job scripts as the `gitlab-runner` user.
 1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation).
-1. During GitLab Runner installation select `shell` as method of executing build scripts or use command:
+1. During GitLab Runner installation select `shell` as method of executing job scripts or use command:
    ```bash
-    $ sudo gitlab-ci-multi-runner register -n \
+    sudo gitlab-ci-multi-runner register -n \
      --url https://gitlab.com/ci \
      --registration-token REGISTRATION_TOKEN \
      --executor shell \
@@ -50,16 +51,17 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user.
 3. Add `gitlab-runner` user to `docker` group:
    ```bash
-    $ sudo usermod -aG docker gitlab-runner
+    sudo usermod -aG docker gitlab-runner
    ```
 4. Verify that `gitlab-runner` has access to Docker:
    ```bash
-    $ sudo -u gitlab-runner -H docker info
+    sudo -u gitlab-runner -H docker info
    ```
    You can now verify that everything works by adding `docker info` to `.gitlab-ci.yml`:
    ```yaml
    before_script:
      - docker info
@@ -80,12 +82,12 @@ For more information please read [On Docker security: `docker` group considered
 The second approach is to use the special docker-in-docker (dind)
 [Docker image](https://hub.docker.com/_/docker/) with all tools installed
-(`docker` and `docker-compose`) and run the build script in context of that
+(`docker` and `docker-compose`) and run the job script in context of that
 image in privileged mode.
 In order to do that, follow the steps:
-1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation).
+1. Install [GitLab Runner](https://docs.gitlab.com/runner/install).
 1. Register GitLab Runner from the command line to use `docker` and `privileged`
   mode:
@@ -155,10 +157,10 @@ not without its own challenges:
  escalation which can lead to container breakout. For more information, check
  out the official Docker documentation on
  [Runtime privilege and Linux capabilities][docker-cap].
- Using docker-in-docker, each build is in a clean environment without the past
+- When using docker-in-docker, each job is in a clean environment without the past
-  history. Concurrent builds work fine because every build gets it's own
+  history. Concurrent jobs work fine because every build gets it's own
  instance of Docker engine so they won't conflict with each other. But this
-  also means builds can be slower because there's no caching of layers.
+  also means jobs can be slower because there's no caching of layers.
 - By default, `docker:dind` uses `--storage-driver vfs` which is the slowest
  form offered. To use a different driver, see
  [Using the overlayfs driver](#using-the-overlayfs-driver).
@@ -171,7 +173,7 @@ The third approach is to bind-mount `/var/run/docker.sock` into the container so
 In order to do that, follow the steps:
-1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation).
+1. Install [GitLab Runner](https://docs.gitlab.com/runner/install).
 1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`:
@@ -187,7 +189,9 @@ In order to do that, follow the steps:
    The above command will register a new Runner to use the special
    `docker:latest` image which is provided by Docker. **Notice that it's using
-    the Docker daemon of the Runner itself, and any containers spawned by docker commands will be siblings of the Runner rather than children of the runner.** This may have complications and limitations that are unsuitable for your workflow.
+    the Docker daemon of the Runner itself, and any containers spawned by docker
+    commands will be siblings of the Runner rather than children of the runner.**
+    This may have complications and limitations that are unsuitable for your workflow.
    The above command will create a `config.toml` entry similar to this:
@@ -206,7 +210,8 @@ In order to do that, follow the steps:
        Insecure = false
    ```
-1. You can now use `docker` in the build script (note that you don't need to include the `docker:dind` service as when using the Docker in Docker executor):
+1. You can now use `docker` in the build script (note that you don't need to
+   include the `docker:dind` service as when using the Docker in Docker executor):
    ```yaml
    image: docker:latest
@@ -221,18 +226,23 @@ In order to do that, follow the steps:
      - docker run my-docker-image /script/to/run/tests
    ```
-While the above method avoids using Docker in privileged mode, you should be aware of the following implications:
+While the above method avoids using Docker in privileged mode, you should be
-* By sharing the docker daemon, you are effectively disabling all
+aware of the following implications:
-the security mechanisms of containers and exposing your host to privilege
-escalation which can lead to container breakout. For example, if a project
+- By sharing the docker daemon, you are effectively disabling all
-ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner
+  the security mechanisms of containers and exposing your host to privilege
-containers.
+  escalation which can lead to container breakout. For example, if a project
-* Concurrent builds may not work; if your tests
+  ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner
-create containers with specific names, they may conflict with each other.
+  containers.
-* Sharing files and directories from the source repo into containers may not
+- Concurrent jobs may not work; if your tests
-work as expected since volume mounting is done in the context of the host
+  create containers with specific names, they may conflict with each other.
-machine, not the build container.
+- Sharing files and directories from the source repo into containers may not
-e.g. `docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests`
+  work as expected since volume mounting is done in the context of the host
+  machine, not the build container, e.g.:
+    ```
+    docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests
+    ```
 ## Using the OverlayFS driver
@@ -299,7 +309,7 @@ push to the Registry connected to your project. Its password is provided in the
 of your Docker images.
 Here's a more elaborate example that splits up the tasks into 4 pipeline stages,
-including two tests that run in parallel. The build is stored in the container
+including two tests that run in parallel. The `build` is stored in the container
 registry and used by subsequent stages, downloading the image
 when needed. Changes to `master` also get tagged as `latest` and deployed using
 an application-specific deploy script:
@@ -360,17 +370,17 @@ deploy:
 Some things you should be aware of when using the Container Registry:
 - You must log in to the container registry before running commands. Putting
-  this in `before_script` will run it before each build job.
+  this in `before_script` will run it before each job.
 - Using `docker build --pull` makes sure that Docker fetches any changes to base
  images before building just in case your cache is stale. It takes slightly
  longer, but means you don’t get stuck without security patches to base images.
 - Doing an explicit `docker pull` before each `docker run` makes sure to fetch
  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
-  image tag makes this less necessary since each build will be unique and you
+  image tag makes this less necessary since each job will be unique and you
  shouldn't ever have a stale image, but it's still possible if you re-build a
  given commit after a dependency has changed.
- You don't want to build directly to `latest` in case there are multiple builds
+- You don't want to build directly to `latest` in case there are multiple jobs
  happening simultaneously.
 [docker-in-docker]: https://blog.docker.com/2013/09/docker-can-now-run-within-docker/

--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -8,7 +8,7 @@ run applications in independent "containers" that are run within a single Linux
 instance. [Docker Hub][hub] has a rich database of pre-built images that can be
 used to test and build your applications.
-Docker, when used with GitLab CI, runs each build in a separate and isolated
+Docker, when used with GitLab CI, runs each job in a separate and isolated
 container using the predefined image that is set up in
 [`.gitlab-ci.yml`](../yaml/README.md).
@@ -45,12 +45,12 @@ can be found at [Docker Hub][hub]. For more information about images and Docker
 Hub please read the [Docker Fundamentals][] documentation.
 In short, with `image` we refer to the docker image, which will be used to
-create a container on which your build will run.
+create a container on which your job will run.
 ## What is a service
 The `services` keyword defines just another docker image that is run during
-your build and is linked to the docker image that the `image` keyword defines.
+your job and is linked to the docker image that the `image` keyword defines.
 This allows you to access the service image during build time.
 The service image can run any application, but the most common use case is to
@@ -61,13 +61,13 @@ time the project is built.
 You can see some widely used services examples in the relevant documentation of
 [CI services examples](../services/README.md).
-### How services are linked to the build
+### How services are linked to the job
 To better understand how the container linking works, read
 [Linking containers together][linking-containers].
 To summarize, if you add `mysql` as service to your application, the image will
-then be used to create a container that is linked to the build container.
+then be used to create a container that is linked to the job container.
 The service container for MySQL will be accessible under the hostname `mysql`.
 So, in order to access your database service you have to connect to the host
@@ -133,7 +133,7 @@ Look for the `[runners.docker]` section:
  services = ["mysql:latest", "postgres:latest"]
 ```
-The image and services defined this way will be added to all builds run by
+The image and services defined this way will be added to all job run by
 that runner.
 ## Define an image from a private Docker registry
@@ -167,7 +167,7 @@ services:
 - tutum/wordpress:latest
 ```
-When the build is run, `tutum/wordpress` will be started and you will have
+When the job is run, `tutum/wordpress` will be started and you will have
 access to it from your build container under the hostname `tutum__wordpress`.
 The alias hostname for the service is made from the image name following these
@@ -202,21 +202,21 @@ See the specific documentation for
 ## How Docker integration works
-Below is a high level overview of the steps performed by docker during build
+Below is a high level overview of the steps performed by docker during job
 time.
 1. Create any service container: `mysql`, `postgresql`, `mongodb`, `redis`.
 1. Create cache container to store all volumes as defined in `config.toml` and
   `Dockerfile` of build image (`ruby:2.1` as in above example).
 1. Create build container and link any service container to build container.
-1. Start build container and send build script to the container.
+1. Start build container and send job script to the container.
-1. Run build script.
+1. Run job script.
 1. Checkout code in: `/builds/group-name/project-name/`.
 1. Run any step defined in `.gitlab-ci.yml`.
 1. Check exit status of build script.
 1. Remove build container and all created service containers.
-## How to debug a build locally
+## How to debug a job locally
 *Note: The following commands are run without root privileges. You should be
 able to run docker with your regular user account.*

--- a/doc/ci/enable_or_disable_ci.md
+++ b/doc/ci/enable_or_disable_ci.md
@@ -11,10 +11,10 @@ API.
 ---
-As of GitLab 8.2, GitLab CI is mainly exposed via the `/builds` page of a
+GitLab CI is exposed via the `/pipelines` and `/builds` pages of a project.
-project. Disabling GitLab CI in a project does not delete any previous builds.
+Disabling GitLab CI in a project does not delete any previous jobs.
-In fact, the `/builds` page can still be accessed, although it's hidden from
+In fact, the `/pipelines` and `/builds` pages can still be accessed, although
-the left sidebar menu.
+it's hidden from the left sidebar menu.
 GitLab CI is enabled by default on new installations and can be disabled either
 individually under each project's settings, or site-wide by modifying the

--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -75,7 +75,7 @@ We have defined 3 [stages](yaml/README.md#stages):
 - deploy
 The jobs assigned to these stages will run in this order. If a job fails, then
-the builds that are assigned to the next stage won't run, rendering the pipeline
+the jobs that are assigned to the next stage won't run, rendering the pipeline
 as failed. In our case, the `test` job will run first, then the `build` and
 lastly the `deploy_staging`. With this, we ensure that first the tests pass,
 then our app is able to be built successfully, and lastly we deploy to the
@@ -119,7 +119,7 @@ There's a bunch of information there, specifically you can see:
 - The environment's name with a link to its deployments
 - The last deployment ID number and who performed it
- The build ID of the last deployment with its respective job name
+- The job ID of the last deployment with its respective job name
 - The commit information of the last deployment such as who committed, to what
  branch and the Git SHA of the commit
 - The exact time the last deployment was performed
@@ -219,9 +219,9 @@ deploy_prod:
 The `when: manual` action exposes a play button in GitLab's UI and the
 `deploy_prod` job will only be triggered if and when we click that play button.
-You can find it in the pipeline, build, environment, and deployment views.
+You can find it in the pipeline, job, environment, and deployment views.
-| Pipelines | Single pipeline | Environments | Deployments | Builds |
+| Pipelines | Single pipeline | Environments | Deployments | jobs |
 | --------- | ----------------| ------------ | ----------- | -------|
 | ![Pipelines manual action](img/environments_manual_action_pipelines.png) | ![Pipelines manual action](img/environments_manual_action_single_pipeline.png) | ![Environments manual action](img/environments_manual_action_environments.png) | ![Deployments manual action](img/environments_manual_action_deployments.png) | ![Builds manual action](img/environments_manual_action_builds.png) |
@@ -419,7 +419,7 @@ Behind the scenes:
 - GitLab Runner picks up the changes and starts running the jobs
 - The jobs run sequentially as defined in `stages`
  - First, the tests pass
-  - Then, the build begins and successfully also passes
+  - Then, the job begins and successfully also passes
  - Lastly, the app is deployed to an environment with a name specific to the
    branch

--- 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

--- 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.

--- 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
+provided by the official php docker image that you can use to easily install
-extensions. For more information read the the documentation at
+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

--- 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

--- a/doc/ci/git_submodules.md
+++ b/doc/ci/git_submodules.md
 # Using Git submodules with GitLab CI
 > **Notes:**
- GitLab 8.12 introduced a new [CI build permissions model][newperms] and you
+- GitLab 8.12 introduced a new [CI job permissions model][newperms] and you
  are encouraged to upgrade your GitLab instance if you haven't done already.
  If you are **not** using GitLab 8.12 or higher, you would need to work your way
  around submodules in order to access the sources of e.g., `gitlab.com/group/project`
  with the use of [SSH keys](ssh_keys/README.md).
- With GitLab 8.12 onward, your permissions are used to evaluate what a CI build
+- With GitLab 8.12 onward, your permissions are used to evaluate what a CI job
  can access. More information about how this system works can be found in the
-  [Build permissions model](../user/permissions.md#builds-permissions).
+  [Jobs permissions model](../user/permissions.md#jobs-permissions).
 - The HTTP(S) Git protocol [must be enabled][gitpro] in your GitLab instance.
 ## Configuring the `.gitmodules` file
@@ -27,7 +27,7 @@ Let's consider the following example:
 If you are using GitLab 8.12+ and your submodule is on the same GitLab server,
 you must update your `.gitmodules` file to use **relative URLs**.
 Since Git allows the usage of relative URLs for your `.gitmodules` configuration,
-this easily allows you to use HTTP(S) for cloning all your CI builds and SSH
+this easily allows you to use HTTP(S) for cloning all your CI jobs and SSH
 for all your local checkouts. The `.gitmodules` would look like:
 ```ini
@@ -38,7 +38,7 @@ for all your local checkouts. The `.gitmodules` would look like:
 The above configuration will instruct Git to automatically deduce the URL that
 should be used when cloning sources. Whether you use HTTP(S) or SSH, Git will use
-that same channel and it will allow to make all your CI builds use HTTP(S)
+that same channel and it will allow to make all your CI jobs use HTTP(S)
 (because GitLab CI only uses HTTP(S) for cloning your sources), and all your local
 clones will continue using SSH.
@@ -57,13 +57,13 @@ Once `.gitmodules` is correctly configured, you can move on to
 ## Using Git submodules in your CI jobs
 There are a few steps you need to take in order to make submodules work
-correctly with your CI builds:
+correctly with your CI jobs:
 1. First, make sure you have used [relative URLs](#configuring-the-gitmodules-file)
   for the submodules located in the same GitLab server.
 1. Next, if you are using `gitlab-ci-multi-runner` v1.10+, you can set the
   `GIT_SUBMODULE_STRATEGY` variable to either `normal` or `recursive` to tell
-   the runner to fetch your submodules before the build:
+   the runner to fetch your submodules before the job:
    ```yaml
    variables:
      GIT_SUBMODULE_STRATEGY: recursive
@@ -87,9 +87,9 @@ 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
 submodule URL including the token in `.git/config`
 (or `.git/modules/<submodule>/config`) based on `.gitmodules` and the current
-remote URL. On subsequent builds 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
-build, and to **a token from a previous build**. `sync` allows to force updating
+job, and to **a token from a previous job**. `sync` allows to force updating
 the full URL.
 [gitpro]: ../user/admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols

--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
-# Introduction to pipelines and builds
+# Introduction to pipelines and jobs
 >**Note:**
 Introduced in GitLab 8.8.
 ## Pipelines
-A pipeline is a group of [builds][] that get executed in [stages][](batches).
+A pipeline is a group of [jobs][] that get executed in [stages][](batches).
-All of the builds in a stage are executed in parallel (if there are enough
+All of the jobs in a stage are executed in parallel (if there are enough
 concurrent [Runners]), and if they all succeed, the pipeline moves on to the
-next stage. If one of the builds fails, the next stage is not (usually)
+next stage. If one of the jobs fails, the next stage is not (usually)
 executed.
 ![Pipelines example](img/pipelines.png)
-## Builds
+## Types of Pipelines
-Builds are individual runs of [jobs]. Not to be confused with a `build` job or
+There are three types of pipelines that often use the single shorthand of "pipeline". People often talk about them as if each one is "the" pipeline, but really, they're just pieces of a single, comprehensive pipeline.
-`build` stage.
+![Types of Pipelines](img/types-of-pipelines.svg)
+1. **CI Pipeline**: Build and test stages defined in `.gitlab-ci.yml`
+2. **Deploy Pipeline**: Deploy stage(s) defined in `.gitlab-ci.yml` The flow of deploying code to servers through various stages: e.g. development to staging to production
+3. **Project Pipeline**: Cross-project CI dependencies [triggered via API]((triggers)), particularly for micro-services, but also for complicated build dependencies: e.g. api -> front-end, ce/ee -> omnibus.
+## Development Workflows
+Pipelines accommodate several development workflows:
+1. **Branch Flow** (e.g. different branch for dev, qa, staging, production)
+2. **Trunk-based Flow** (e.g. feature branches and single master branch, possibly with tags for releases)
+3. **Fork-based Flow** (e.g. merge requests come from forks)
+Example continuous delivery flow:
+![CD Flow](img/pipelines-goal.svg)
+## Jobs
+Jobs can be defined in the [`.gitlab-ci.yml`][jobs-yaml] file. Not to be
+confused with a `build` job or `build` stage.
 ## Defining pipelines
@@ -30,11 +52,11 @@ See full [documentation](yaml/README.md#jobs).
 You can find the current and historical pipeline runs under **Pipelines** for
 your project.
-## Seeing build status
+## Seeing job status
-Clicking on a pipeline will show the builds that were run for that pipeline.
+Clicking on a pipeline will show the jobs that were run for that pipeline.
-Clicking on an individual build will show you its build trace, and allow you to
+Clicking on an individual job will show you its job trace, and allow you to
-cancel the build, retry it,  or erase the build trace.
+cancel the job, retry it,  or erase the job trace.
 ## How the pipeline duration is calculated
@@ -69,11 +91,11 @@ total running time should be:
 ## Badges
-Build status and test coverage report badges are available. You can find their
+Job status and test coverage report badges are available. You can find their
 respective link in the [Pipelines settings] page.
-[builds]: #builds
+[jobs]: #jobs
-[jobs]: yaml/README.md#jobs
+[jobs-yaml]: yaml/README.md#jobs
 [stages]: yaml/README.md#stages
 [runners]: runners/README.html
 [pipelines settings]: ../user/project/pipelines/settings.md
--- a/doc/ci/quick_start/README.md
+++ b/doc/ci/quick_start/README.md
-# Quick Start
+# Getting started with GitLab CI
 >**Note:** Starting from version 8.0, GitLab [Continuous Integration][ci] (CI)
 is fully integrated into GitLab itself and is [enabled] by default on all
@@ -7,7 +7,7 @@ projects.
 GitLab offers a [continuous integration][ci] service. If you
 [add a `.gitlab-ci.yml` file][yaml] to the root directory of your repository,
 and configure your GitLab project to use a [Runner], then each merge request or
-push triggers your CI [pipeline].
+push, triggers your CI [pipeline].
 The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs
 a pipeline with three [stages]: `build`, `test`, and `deploy`. You don't need to
@@ -31,13 +31,13 @@ So in brief, the steps needed to have a working CI can be summed up to:
 From there on, on every push to your Git repository, the Runner will
 automagically start the pipeline and the pipeline will appear under the
-project's `/pipelines` page.
+project's **Pipelines** page.
 ---
 This guide assumes that you:
- have a working GitLab instance of version 8.0 or higher or are using
+- have a working GitLab instance of version 8.0+r or are using
  [GitLab.com](https://gitlab.com)
 - have a project in GitLab that you would like to use CI for
@@ -54,7 +54,7 @@ The `.gitlab-ci.yml` file is where you configure what CI does with your project.
 It lives in the root of your repository.
 On any push to your repository, GitLab will look for the `.gitlab-ci.yml`
-file and start builds on _Runners_ according to the contents of the file,
+file and start jobs on _Runners_ according to the contents of the file,
 for that commit.
 Because `.gitlab-ci.yml` is in the repository and is version controlled, old
@@ -63,11 +63,12 @@ have different pipelines and jobs, and you have a single source of truth for CI.
 You can read more about the reasons why we are using `.gitlab-ci.yml` [in our
 blog about it][blog-ci].
-**Note:** `.gitlab-ci.yml` is a [YAML](https://en.wikipedia.org/wiki/YAML) file
-so you have to pay extra attention to indentation. Always use spaces, not tabs.
 ### Creating a simple `.gitlab-ci.yml` file
+>**Note:**
+`.gitlab-ci.yml` is a [YAML](https://en.wikipedia.org/wiki/YAML) file
+so you have to pay extra attention to indentation. Always use spaces, not tabs.
 You need to create a file named `.gitlab-ci.yml` in the root directory of your
 repository. Below is an example for a Ruby on Rails project.
@@ -88,7 +89,7 @@ rubocop:
    - bundle exec rubocop
 ```
-This is the simplest possible build configuration that will work for most Ruby
+This is the simplest possible configuration that will work for most Ruby
 applications:
 1. Define two jobs `rspec` and `rubocop` (the names are arbitrary) with
@@ -98,22 +99,22 @@ applications:
 The `.gitlab-ci.yml` file defines sets of jobs with constraints of how and when
 they should be run. The jobs are defined as top-level elements with a name (in
 our case `rspec` and `rubocop`) and always have to contain the `script` keyword.
-Jobs are used to create builds, which are then picked by
+Jobs are used to create jobs, which are then picked by
 [Runners](../runners/README.md) and executed within the environment of the Runner.
 What is important is that each job is run independently from each other.
 If you want to check whether your `.gitlab-ci.yml` file is valid, there is a
 Lint tool under the page `/ci/lint` of your GitLab instance. You can also find
-a "CI Lint" button to go to this page under **Pipelines > Pipelines** and
+a "CI Lint" button to go to this page under **Pipelines ➔ Pipelines** and
-**Pipelines > Builds** in your project.
+**Pipelines ➔ Jobs** in your project.
 For more information and a complete `.gitlab-ci.yml` syntax, please read
-[the documentation on .gitlab-ci.yml](../yaml/README.md).
+[the reference documentation on .gitlab-ci.yml](../yaml/README.md).
 ### Push `.gitlab-ci.yml` to GitLab
-Once you've created `.gitlab-ci.yml`, you should add it to your git repository
+Once you've created `.gitlab-ci.yml`, you should add it to your Git repository
 and push it to GitLab.
 ```bash
@@ -125,28 +126,27 @@ git push origin master
 Now if you go to the **Pipelines** page you will see that the pipeline is
 pending.
-You can also go to the **Commits** page and notice the little clock icon next
+You can also go to the **Commits** page and notice the little pause icon next
 to the commit SHA.
 ![New commit pending](img/new_commit.png)
-Clicking on the clock icon you will be directed to the builds page for that
+Clicking on it you will be directed to the jobs page for that specific commit.
-specific commit.
-![Single commit builds page](img/single_commit_status_pending.png)
+![Single commit jobs page](img/single_commit_status_pending.png)
 Notice that there are two jobs pending which are named after what we wrote in
 `.gitlab-ci.yml`. The red triangle indicates that there is no Runner configured
-yet for these builds.
+yet for these jobs.
-The next step is to configure a Runner so that it picks the pending builds.
+The next step is to configure a Runner so that it picks the pending jobs.
 ## Configuring a Runner
-In GitLab, Runners run the builds that you define in `.gitlab-ci.yml`. A Runner
+In GitLab, Runners run the jobs that you define in `.gitlab-ci.yml`. A Runner
 can be a virtual machine, a VPS, a bare-metal machine, a docker container or
 even a cluster of containers. GitLab and the Runners communicate through an API,
-so the only requirement is that the Runner's machine has Internet access.
+so the only requirement is that the Runner's machine has [Internet] access.
 A Runner can be specific to a certain project or serve multiple projects in
 GitLab. If it serves all projects it's called a _Shared Runner_.
@@ -155,9 +155,9 @@ Find more information about different Runners in the
 [Runners](../runners/README.md) documentation.
 You can find whether any Runners are assigned to your project by going to
-**Settings > Runners**. Setting up a Runner is easy and straightforward. The
+**Settings ➔ Runners**. Setting up a Runner is easy and straightforward. The
-official Runner supported by GitLab is written in Go and can be found at
+official Runner supported by GitLab is written in Go and its documentation
-<https://gitlab.com/gitlab-org/gitlab-ci-multi-runner>.
+can be found at <https://docs.gitlab.com/runner/>.
 In order to have a functional Runner you need to follow two steps:
@@ -167,28 +167,25 @@ In order to have a functional Runner you need to follow two steps:
 Follow the links above to set up your own Runner or use a Shared Runner as
 described in the next section.
-For other types of unofficial Runners written in other languages, see the
-[instructions for the various GitLab Runners](https://about.gitlab.com/gitlab-ci/#gitlab-runner).
 Once the Runner has been set up, you should see it on the Runners page of your
-project, following **Settings > Runners**.
+project, following **Settings ➔ Runners**.
 ![Activated runners](img/runners_activated.png)
 ### Shared Runners
-If you use [GitLab.com](https://gitlab.com/) you can use **Shared Runners**
+If you use [GitLab.com](https://gitlab.com/) you can use the **Shared Runners**
 provided by GitLab Inc.
 These are special virtual machines that run on GitLab's infrastructure and can
 build any project.
-To enable **Shared Runners** you have to go to your project's
+To enable the **Shared Runners** you have to go to your project's
-**Settings > Runners** and click **Enable shared runners**.
+**Settings ➔ Runners** and click **Enable shared runners**.
 [Read more on Shared Runners](../runners/README.md).
-## Seeing the status of your pipeline and builds
+## Seeing the status of your pipeline and jobs
 After configuring the Runner successfully, you should see the status of your
 last commit change from _pending_ to either _running_, _success_ or _failed_.
@@ -197,23 +194,23 @@ You can view all pipelines by going to the **Pipelines** page in your project.
 ![Commit status](img/pipelines_status.png)
-Or you can view all builds, by going to the **Pipelines > Builds** page.
+Or you can view all jobs, by going to the **Pipelines ➔ Jobs** page.
 ![Commit status](img/builds_status.png)
-By clicking on a Build ID, you will be able to see the log of that build.
+By clicking on a job's status, you will be able to see the log of that job.
-This is important to diagnose why a build failed or acted differently than
+This is important to diagnose why a job failed or acted differently than
 you expected.
 ![Build log](img/build_log.png)
 You are also able to view the status of any commit in the various pages in
-GitLab, such as **Commits** and **Merge Requests**.
+GitLab, such as **Commits** and **Merge requests**.
 ## Enabling build emails
 If you want to receive e-mail notifications about the result status of the
-builds, you should explicitly enable the **Builds Emails** service under your
+jobs, you should explicitly enable the **Builds Emails** service under your
 project's settings.
 For more information read the
@@ -224,9 +221,7 @@ For more information read the
 Visit the [examples README][examples] to see a list of examples using GitLab
 CI with various languages.
-Awesome! You started using CI in GitLab!
+[runner-install]: https://docs.gitlab.com/runner/install/
-[runner-install]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/tree/master#install-gitlab-runner
 [blog-ci]: https://about.gitlab.com/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
 [examples]: ../examples/README.md
 [ci]: https://about.gitlab.com/gitlab-ci/
@@ -235,3 +230,4 @@ Awesome! You started using CI in GitLab!
 [enabled]: ../enable_or_disable_ci.md
 [stages]: ../yaml/README.md#stages
 [pipeline]: ../pipelines.md
+[internet]: https://about.gitlab.com/images/theinternet.png
--- a/doc/ci/quick_start/img/build_log.png
+++ b/doc/ci/quick_start/img/build_log.png
--- a/doc/ci/quick_start/img/builds_status.png
+++ b/doc/ci/quick_start/img/builds_status.png
--- a/doc/ci/quick_start/img/new_commit.png
+++ b/doc/ci/quick_start/img/new_commit.png
--- a/doc/ci/quick_start/img/pipelines_status.png
+++ b/doc/ci/quick_start/img/pipelines_status.png
--- a/doc/ci/quick_start/img/runners_activated.png
+++ b/doc/ci/quick_start/img/runners_activated.png
--- a/doc/ci/quick_start/img/single_commit_status_pending.png
+++ b/doc/ci/quick_start/img/single_commit_status_pending.png
--- a/doc/ci/quick_start/img/status_pending.png
+++ b/doc/ci/quick_start/img/status_pending.png
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
--- a/doc/ci/services/mysql.md
+++ b/doc/ci/services/mysql.md
@@ -31,7 +31,7 @@ Database: el_duderino
 ```
 If you are wondering why we used `mysql` for the `Host`, read more at
-[How is service linked to the build](../docker/using_docker_images.md#how-is-service-linked-to-the-build).
+[How is service linked to the job](../docker/using_docker_images.md#how-is-service-linked-to-the-job).
 You can also use any other docker image available on [Docker Hub][hub-mysql].
 For example, to use MySQL 5.5 the service becomes `mysql:5.5`.
@@ -112,7 +112,7 @@ convenience 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.
 [hub-mysql]: https://hub.docker.com/r/_/mysql/
 [mysql-example-repo]: https://gitlab.com/gitlab-examples/mysql
--- a/doc/ci/services/postgres.md
+++ b/doc/ci/services/postgres.md
@@ -31,7 +31,7 @@ Database: nice_marmot
 ```
 If you are wondering why we used `postgres` for the `Host`, read more at
-[How is service linked to the build](../docker/using_docker_images.md#how-is-service-linked-to-the-build).
+[How is service linked to the job](../docker/using_docker_images.md#how-is-service-linked-to-the-job).
 You can also use any other docker image available on [Docker Hub][hub-pg].
 For example, to use PostgreSQL 9.3 the service becomes `postgres:9.3`.
@@ -108,7 +108,7 @@ convenience 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.
 [hub-pg]: https://hub.docker.com/r/_/postgres/
 [postgres-example-repo]: https://gitlab.com/gitlab-examples/postgres
--- a/doc/ci/services/redis.md
+++ b/doc/ci/services/redis.md
@@ -63,7 +63,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.
 [hub-redis]: https://hub.docker.com/r/_/redis/
 [redis-example-repo]: https://gitlab.com/gitlab-examples/redis
--- a/doc/ci/ssh_keys/README.md
+++ b/doc/ci/ssh_keys/README.md
@@ -25,7 +25,7 @@ This is the universal solution which works with any type of executor
 1. Create a new SSH key pair with [ssh-keygen][]
 2. Add the private key as a **Secret Variable** to the project
-3. Run the [ssh-agent][] during build to load the private key.
+3. Run the [ssh-agent][] during job to load the private key.
 ## SSH keys when using the Docker executor
@@ -77,7 +77,7 @@ SSH key.
 You can generate the SSH key from the machine that GitLab Runner is installed
 on, and use that key for all projects that are run on this machine.
-First, you need to login to the server that runs your builds.
+First, you need to login to the server that runs your jobs.
 Then from the terminal login as the `gitlab-runner` user and generate the SSH
 key pair as described in the [SSH keys documentation](../../ssh/README.md).
@@ -103,7 +103,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.
 [ssh-keygen]: http://linux.die.net/man/1/ssh-keygen
 [ssh-agent]: http://linux.die.net/man/1/ssh-agent

--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
-# Triggering Builds through the API
+# Triggering jobs through the API
-> [Introduced][ci-229] in GitLab CE 7.14.
 > **Note**:
-GitLab 8.12 has a completely redesigned build permissions system.
+- [Introduced][ci-229] in GitLab CE 7.14.
-Read all about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#build-triggers).
+- GitLab 8.12 has a completely redesigned job permissions system. Read all
+  about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers).
 Triggers can be used to force a rebuild of a specific `ref` (branch or tag)
 with an API call.
 ## Add a trigger
-You can add a new trigger by going to your project's **Settings > Triggers**.
+You can add a new trigger by going to your project's
-The **Add trigger** button will create a new token which you can then use to
+**Settings ➔ CI/CD Pipelines ➔ Triggers**. The **Add trigger** button will
-trigger a rebuild of this particular project.
+create a new token which you can then use to trigger a rerun of this
+particular project's pipeline.
 Every new trigger you create, gets assigned a different token which you can
 then use inside your scripts or `.gitlab-ci.yml`. You also have a nice
@@ -27,13 +27,13 @@ You can revoke a trigger any time by going at your project's
 **Settings > Triggers** and hitting the **Revoke** button. The action is
 irreversible.
-## Trigger a build
+## Trigger a job
 > **Note**:
 Valid refs are only the branches and tags. If you pass a commit SHA as a ref,
-it will not trigger a build.
+it will not trigger a job.
-To trigger a build you need to send a `POST` request to GitLab's API endpoint:
+To trigger a job you need to send a `POST` request to GitLab's API endpoint:
 ```
 POST /projects/:id/trigger/builds
@@ -42,31 +42,32 @@ POST /projects/:id/trigger/builds
 The required parameters are the trigger's `token` and the Git `ref` on which
 the trigger will be performed. Valid refs are the branch and the tag. The `:id`
 of a project can be found by [querying the API](../../api/projects.md)
-or by visiting the **Triggers** page which provides self-explanatory examples.
+or by visiting the **CI/CD Pipelines** settings page which provides
+self-explanatory examples.
-When a rebuild is triggered, the information is exposed in GitLab's UI under
+When a rerun of a pipeline is triggered, the information is exposed in GitLab's
-the **Builds** page and the builds are marked as `triggered`.
+UI under the **Jobs** page and the jobs are marked as triggered 'by API'.
-![Marked rebuilds as triggered on builds page](img/builds_page.png)
+![Marked rebuilds as  on jobs page](img/builds_page.png)
 ---
-You can see which trigger caused the rebuild by visiting the single build page.
+You can see which trigger caused the rebuild by visiting the single job page.
-The token of the trigger is exposed in the UI as you can see from the image
+A part of the trigger's token is exposed in the UI as you can see from the image
 below.
-![Marked rebuilds as triggered on a single build page](img/trigger_single_build.png)
+![Marked rebuilds as triggered on a single job page](img/trigger_single_build.png)
 ---
 See the [Examples](#examples) section for more details on how to actually
 trigger a rebuild.
-## Trigger a build from webhook
+## Trigger a job from webhook
 > Introduced in GitLab 8.14.
-To trigger a build from webhook of another project you need to add the following
+To trigger a job from webhook of another project you need to add the following
 webhook url for Push and Tag push events:
 ```
@@ -78,7 +79,7 @@ https://gitlab.example.com/api/v3/projects/:id/ref/:ref/trigger/builds?token=TOK
  from webhook body that designates the branchref that fired the trigger in the source repository.
 - `ref` should be url encoded if contains slashes.
-## Pass build variables to a trigger
+## Pass job variables to a trigger
 You can pass any number of arbitrary variables in the trigger API call and they
 will be available in GitLab CI so that they can be used in your `.gitlab-ci.yml`
@@ -90,7 +91,7 @@ variables[key]=value
 This information is also exposed in the UI.
-![Build variables in UI](img/trigger_variables.png)
+![Job variables in UI](img/trigger_variables.png)
 ---
@@ -116,7 +117,7 @@ curl --request POST \
    "https://gitlab.example.com/api/v3/projects/9/trigger/builds?token=TOKEN&ref=master"
 ```
-### Triggering a build within `.gitlab-ci.yml`
+### Triggering a job within `.gitlab-ci.yml`
 You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
 you have two projects, A and B, and you want to trigger a rebuild on the `master`
@@ -132,7 +133,7 @@ build_docs:
  - tags
 ```
-Now, whenever a new tag is pushed on project A, the build will run and the
+Now, whenever a new tag is pushed on project A, the job will run and the
 `build_docs` job will be executed, triggering a rebuild of project B. The
 `stage: deploy` ensures that this job will run only after all jobs with
 `stage: test` complete successfully.
@@ -189,18 +190,18 @@ curl --request POST \
  https://gitlab.example.com/api/v3/projects/9/trigger/builds
 ```
-### Using webhook to trigger builds
+### Using webhook to trigger job
-You can add the following webhook to another project in order to trigger a build:
+You can add the following webhook to another project in order to trigger a job:
 ```
 https://gitlab.example.com/api/v3/projects/9/ref/master/trigger/builds?token=TOKEN&variables[UPLOAD_TO_S3]=true
 ```
-### Using cron to trigger nightly builds
+### Using cron to trigger nightly jobs
-Whether you craft a script or just run cURL directly, you can trigger builds
+Whether you craft a script or just run cURL directly, you can trigger jobs
-in conjunction with cron. The example below triggers a build on the `master`
+in conjunction with cron. The example below triggers a job on the `master`
 branch of project with ID `9` every night at `00:30`:
 ```bash

--- a/doc/ci/triggers/img/builds_page.png
+++ b/doc/ci/triggers/img/builds_page.png
--- a/doc/ci/triggers/img/trigger_single_build.png
+++ b/doc/ci/triggers/img/trigger_single_build.png
--- a/doc/ci/triggers/img/trigger_variables.png
+++ b/doc/ci/triggers/img/trigger_variables.png
--- a/doc/ci/triggers/img/triggers_page.png
+++ b/doc/ci/triggers/img/triggers_page.png
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -69,7 +69,7 @@ experience, refactors the existing code). Then:
  someone else would be confused by it as well.
 - After a round of line notes, it can be helpful to post a summary note such as
  "LGTM :thumbsup:", or "Just a couple things to address."
- Avoid accepting a merge request before the build succeeds. Of course, "Merge
+- Avoid accepting a merge request before the job succeeds. Of course, "Merge
  When Pipeline Succeeds" (MWPS) is fine.
 - If you set the MR to "Merge When Pipeline Succeeds", you should take over
  subsequent revisions for anything that would be spotted after that.

--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -307,7 +307,7 @@ sudo usermod -aG redis git
    # now that files in public/uploads are served by gitlab-workhorse
    sudo chmod 0700 public/uploads
-    # Change the permissions of the directory where CI build traces are stored
+    # Change the permissions of the directory where CI job traces are stored
    sudo chmod -R u+rwX builds/
    # Change the permissions of the directory where CI artifacts are stored

--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -44,8 +44,8 @@ environment variable `SKIP`. You can skip:
 - `db` (database)
 - `uploads` (attachments)
 - `repositories` (Git repositories data)
- `builds` (CI build output logs)
+- `builds` (CI job output logs)
- `artifacts` (CI build artifacts)
+- `artifacts` (CI job artifacts)
 - `lfs` (LFS objects)
 - `registry` (Container Registry images)

--- a/doc/university/glossary/README.md
+++ b/doc/university/glossary/README.md
@@ -65,8 +65,8 @@ A branch is a parallel version of a repository. This allows you to work on the r
 Having your own logo on [your GitLab instance login page](https://docs.gitlab.com/ee/customization/branded_login_page.html) instead of the GitLab logo.
-### Build triggers
+### Job triggers
-These protect your code base against breaks, for instance when a team is working on the same project. Learn about [setting up](https://docs.gitlab.com/ce/ci/triggers/README.html) build triggers.
+These protect your code base against breaks, for instance when a team is working on the same project. Learn about [setting up](https://docs.gitlab.com/ce/ci/triggers/README.html) job triggers.
 ### CEPH

--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -2,9 +2,9 @@
 ## Maximum artifacts size
-The maximum size of the [build artifacts][art-yml] can be set in the Admin area
+The maximum size of the [job artifacts][art-yml] can be set in the Admin area
 of your GitLab instance. The value is in MB and the default is 100MB. Note that
-this setting is set for each build.
+this setting is set for each job.
 1. Go to the **Admin area ➔ Settings** (`/admin/application_settings`).
@@ -70,5 +70,5 @@ the group.
 ![Group pipelines quota](img/group_pipelines_quota.png)
-[art-yml]: ../../../administration/build_artifacts.md
+[art-yml]: ../../../administration/job_artifacts.md
 [ee-1078]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1078
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -22,9 +22,9 @@ The following table depicts the various user permission levels in a project.
 | Create confidential issue             | ✓       | ✓          | ✓           | ✓        | ✓      |
 | View confidential issues              | (✓) [^1] | ✓          | ✓           | ✓        | ✓      |
 | Leave comments                        | ✓       | ✓          | ✓           | ✓        | ✓      |
-| See a list of builds                  | ✓ [^2]  | ✓          | ✓           | ✓        | ✓      |
+| See a list of jobs                    | ✓ [^2]  | ✓          | ✓           | ✓        | ✓      |
-| See a build log                       | ✓ [^2]  | ✓          | ✓           | ✓        | ✓      |
+| See a job   log                       | ✓ [^2]  | ✓          | ✓           | ✓        | ✓      |
-| Download and browse build artifacts   | ✓ [^2]  | ✓          | ✓           | ✓        | ✓      |
+| Download and browse job artifacts     | ✓ [^2]  | ✓          | ✓           | ✓        | ✓      |
 | View wiki pages                       | ✓       | ✓          | ✓           | ✓        | ✓      |
 | Pull project code                     |         | ✓          | ✓           | ✓        | ✓      |
 | Download project                      |         | ✓          | ✓           | ✓        | ✓      |
@@ -46,7 +46,7 @@ The following table depicts the various user permission levels in a project.
 | Remove non-protected branches         |         |            | ✓           | ✓        | ✓      |
 | Add tags                              |         |            | ✓           | ✓        | ✓      |
 | Write a wiki                          |         |            | ✓           | ✓        | ✓      |
-| Cancel and retry builds               |         |            | ✓           | ✓        | ✓      |
+| Cancel and retry jobs                 |         |            | ✓           | ✓        | ✓      |
 | Create or update commit status        |         |            | ✓           | ✓        | ✓      |
 | Update a container registry           |         |            | ✓           | ✓        | ✓      |
 | Remove a container registry image     |         |            | ✓           | ✓        | ✓      |
@@ -60,7 +60,7 @@ The following table depicts the various user permission levels in a project.
 | Add deploy keys to project            |         |            |             | ✓        | ✓      |
 | Configure project hooks               |         |            |             | ✓        | ✓      |
 | Manage runners                        |         |            |             | ✓        | ✓      |
-| Manage build triggers                 |         |            |             | ✓        | ✓      |
+| Manage job triggers                   |         |            |             | ✓        | ✓      |
 | Manage variables                      |         |            |             | ✓        | ✓      |
 | Manage pages                          |         |            |             | ✓        | ✓      |
 | Manage pages domains and certificates |         |            |             | ✓        | ✓      |
@@ -134,8 +134,8 @@ instance and project. In addition, all admins can use the admin interface under
 | Action                                | Guest, Reporter | Developer   | Master   | Admin  |
 |---------------------------------------|-----------------|-------------|----------|--------|
-| See commits and builds                | ✓               | ✓           | ✓        | ✓      |
+| See commits and jobs                  | ✓               | ✓           | ✓        | ✓      |
-| Retry or cancel build                 |                 | ✓           | ✓        | ✓      |
+| Retry or cancel job                   |                 | ✓           | ✓        | ✓      |
 | Remove project                        |                 |             | ✓        | ✓      |
 | Create project                        |                 |             | ✓        | ✓      |
 | Change project configuration          |                 |             | ✓        | ✓      |
@@ -144,18 +144,18 @@ instance and project. In addition, all admins can use the admin interface under
 | See events in the system              |                 |             |          | ✓      |
 | Admin interface                       |                 |             |          | ✓      |
-### Builds permissions
+### Jobs permissions
 >**Note:**
-GitLab 8.12 has a completely redesigned build permissions system.
+GitLab 8.12 has a completely redesigned job permissions system.
 Read all about the [new model and its implications][new-mod].
-This table shows granted privileges for builds triggered by specific types of
+This table shows granted privileges for jobs triggered by specific types of
 users:
 | Action                                      | Guest, Reporter | Developer   | Master   | Admin  |
 |---------------------------------------------|-----------------|-------------|----------|--------|
-| Run CI build                                |                 | ✓           | ✓        | ✓      |
+| Run CI job                                  |                 | ✓           | ✓        | ✓      |
 | Clone source and LFS from current project   |                 | ✓           | ✓        | ✓      |
 | Clone source and LFS from public projects   |                 | ✓           | ✓        | ✓      |
 | Clone source and LFS from internal projects |                 | ✓ [^4]      | ✓ [^4]   | ✓      |

--- a/doc/user/project/builds/artifacts.md
+++ b/doc/user/project/builds/artifacts.md
-# Introduction to build artifacts
+This document was moved to [pipelines/job_artifacts](../pipelines/job_artifacts.md).
->**Notes:**
->- Since GitLab 8.2 and GitLab Runner 0.7.0, build artifacts that are created by
-   GitLab Runner are uploaded to GitLab and are downloadable as a single archive
-   (`tar.gz`) using the GitLab UI.
->- Starting from GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
-   changed to `ZIP`, and it is now possible to browse its contents, with the added
-   ability of downloading the files separately.
->- The artifacts browser will be available only for new artifacts that are sent
-   to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
-   browse old artifacts already uploaded to GitLab.
->- This is the user documentation. For the administration guide see
-   [administration/build_artifacts.md](../../../administration/build_artifacts.md).
-Artifacts is a list of files and directories which are attached to a build
-after it completes successfully.  This feature is enabled by default in all GitLab installations.
-## Defining artifacts in `.gitlab-ci.yml`
-A simple example of using the artifacts definition in `.gitlab-ci.yml` would be
-the following:
-```yaml
-pdf:
-  script: xelatex mycv.tex
-  artifacts:
-    paths:
-    - mycv.pdf
-```
-A job named `pdf` calls the `xelatex` command in order to build a pdf file from
-the latex source file `mycv.tex`. We then define the `artifacts` paths which in
-turn are defined with the `paths` keyword. All paths to files and directories
-are relative to the repository that was cloned during the build.
-For more examples on artifacts, follow the artifacts reference in
-[`.gitlab-ci.yml` documentation](../../../ci/yaml/README.md#artifacts).
-## Browsing build artifacts
-When GitLab receives an artifacts archive, an archive metadata file is also
-generated. This metadata file describes all the entries that are located in the
-artifacts archive itself. The metadata file is in a binary format, with
-additional GZIP compression.
-GitLab does not extract the artifacts archive in order to save space, memory
-and disk I/O. It instead inspects the metadata file which contains all the
-relevant information. This is especially important when there is a lot of
-artifacts, or an archive is a very large file.
---
-After a build finishes, if you visit the build's specific page, you can see
-that there are two buttons. One is for downloading the artifacts archive and
-the other for browsing its contents.
-![Build artifacts browser button](img/build_artifacts_browser_button.png)
---
-The archive browser shows the name and the actual file size of each file in the
-archive. If your artifacts contained directories, then you are also able to
-browse inside them.
-Below you can see how browsing looks like. In this case we have browsed inside
-the archive and at this point there is one directory and one HTML file.
-![Build artifacts browser](img/build_artifacts_browser.png)
---
-## Downloading build artifacts
->**Note:**
-GitLab does not extract the entire artifacts archive to send just a single file
-to the user. When clicking on a specific file, [GitLab Workhorse] extracts it
-from the archive and the download begins. This implementation saves space,
-memory and disk I/O.
-If you need to download the whole archive, there are buttons in various places
-inside GitLab that make that possible.
-1. While on the pipelines page, you can see the download icon for each build's
-   artifacts archive in the right corner:
-    ![Build artifacts in Pipelines page](img/build_artifacts_pipelines_page.png)
-1. While on the builds page, you can see the download icon for each build's
-   artifacts archive in the right corner:
-    ![Build artifacts in Builds page](img/build_artifacts_builds_page.png)
-1. While inside a specific build, you are presented with a download button
-   along with the one that browses the archive:
-    ![Build artifacts browser button](img/build_artifacts_browser_button.png)
-1. And finally, when browsing an archive you can see the download button at
-   the top right corner:
-    ![Build artifacts browser](img/build_artifacts_browser.png)
-## Downloading the latest build artifacts
-It is possible to download the latest artifacts of a build via a well known URL
-so you can use it for scripting purposes.
-The structure of the URL is the following:
-```
-https://example.com/<namespace>/<project>/builds/artifacts/<ref>/download?job=<job_name>
-```
-For example, to download the latest artifacts of the job named `rspec 6 20` of
-the `master` branch of the `gitlab-ce` project that belongs to the `gitlab-org`
-namespace, the URL would be:
-```
-https://gitlab.com/gitlab-org/gitlab-ce/builds/artifacts/master/download?job=rspec+6+20
-```
-The latest builds are also exposed in the UI in various places. Specifically,
-look for the download button in:
- the main project's page
- the branches page
- the tags page
-If the latest build has failed to upload the artifacts, you can see that
-information in the UI.
-![Latest artifacts button](img/build_latest_artifacts_browser.png)
-[gitlab workhorse]: https://gitlab.com/gitlab-org/gitlab-workhorse "GitLab Workhorse repository"
--- a/doc/user/project/builds/img/build_artifacts_browser.png
+++ b/doc/user/project/builds/img/build_artifacts_browser.png
--- a/doc/user/project/builds/img/build_artifacts_browser_button.png
+++ b/doc/user/project/builds/img/build_artifacts_browser_button.png
--- a/doc/user/project/builds/img/build_artifacts_builds_page.png
+++ b/doc/user/project/builds/img/build_artifacts_builds_page.png
--- a/doc/user/project/builds/img/build_artifacts_pipelines_page.png
+++ b/doc/user/project/builds/img/build_artifacts_pipelines_page.png
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -11,7 +11,7 @@ a new issue is created. You can configure webhooks to listen for specific events
 like pushes, issues or merge requests. GitLab will send a POST request with data
 to the webhook URL.
-Webhooks can be used to update an external issue tracker, trigger CI builds,
+Webhooks can be used to update an external issue tracker, trigger CI jobs,
 update a backup mirror, or even deploy to your production server.
 Navigate to the webhooks page by going to the **Integrations** page from your

--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -22,7 +22,7 @@ in a merged merge requests or a commit.
 ## Merge when pipeline succeeds
 When reviewing a merge request that looks ready to merge but still has one or
-more CI builds running, you can set it to be merged automatically when CI
+more CI jobs running, you can set it to be merged automatically when CI
 pipeline succeeds. This way, you don't have to wait for the pipeline to finish
 and remember to merge the request manually.

--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
 # Merge When Pipeline Succeeds
 When reviewing a merge request that looks ready to merge but still has one or
-more CI builds running, you can set it to be merged automatically when the
+more CI jobs running, you can set it to be merged automatically when the
-builds pipeline succeeds. This way, you don't have to wait for the builds to
+jobs pipeline succeeds. This way, you don't have to wait for the jobs to
 finish and remember to merge the request manually.
 ![Enable](img/merge_when_build_succeeds_enable.png)
@@ -19,10 +19,10 @@ after all.
 ![Status](img/merge_when_build_succeeds_status.png)
 When the pipeline succeeds, the merge request will automatically be merged.
-When the pipeline fails, the author gets a chance to retry any failed builds,
+When the pipeline fails, the author gets a chance to retry any failed jobs,
 or to push new commits to fix the failure.
-When the builds are retried and succeed on the second try, the merge request
+When the jobs are retried and succeed on the second try, the merge request
 will automatically be merged after all. When the merge request is updated with
 new commits, the automatic merge is automatically canceled to allow the new
 changes to be reviewed.
@@ -30,7 +30,7 @@ changes to be reviewed.
 ## Only allow merge requests to be merged if the pipeline succeeds
 > **Note:**
-You need to have builds configured to enable this feature.
+You need to have jobs configured to enable this feature.
 You can prevent merge requests from being merged if their pipeline did not succeed.
@@ -41,6 +41,6 @@ hit **Save** for the changes to take effect.
 ![Only allow merge if pipeline succeeds settings](img/merge_when_build_succeeds_only_if_succeeds_settings.png)
 From now on, every time the pipeline fails you will not be able to merge the
-merge request from the UI, until you make all relevant builds pass.
+merge request from the UI, until you make all relevant jobs pass.
 ![Only allow merge if pipeline succeeds message](img/merge_when_build_succeeds_only_if_succeeds_msg.png)
--- a/doc/user/project/new_ci_build_permissions_model.md
+++ b/doc/user/project/new_ci_build_permissions_model.md
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -100,7 +100,7 @@ whereas a group's project under `http(s)://groupname.example.io/projectname`.
 The key thing about GitLab Pages is the `.gitlab-ci.yml` file, something that
 gives you absolute control over the build process. You can actually watch your
-website being built live by following the CI build traces.
+website being built live by following the CI job traces.
 > **Note:**
 > Before reading this section, make sure you familiarize yourself with GitLab CI
@@ -127,7 +127,7 @@ pages:
 ```
 When the Runner reaches to build the `pages` job, it executes whatever is
-defined in the `script` parameter and if the build completes with a non-zero
+defined in the `script` parameter and if the job completes with a non-zero
 exit status, it then uploads the `public/` directory to GitLab Pages.
 The `public/` directory should contain all the static content of your website.
@@ -211,11 +211,11 @@ pages:                      # the build job must be named pages
 ```
 Here, we used the Docker executor and in the first line we specified the base
-image against which our builds will run.
+image against which our jobs will run.
 You have to make sure that the generated static files are ultimately placed
 under the `public` directory, that's why in the `script` section we run the
-`jekyll` command that builds the website and puts all content in the `public/`
+`jekyll` command that jobs the website and puts all content in the `public/`
 directory. Depending on the static generator of your choice, this command will
 differ. Search in the documentation of the static generator you will use if
 there is an option to explicitly set the output directory. If there is not
@@ -403,7 +403,7 @@ don't have to create and edit HTML files manually. For example, Jekyll has the
 ### Can I download my generated pages?
-Sure. All you need to do is download the artifacts archive from the build page.
+Sure. All you need to do is download the artifacts archive from the job page.
 ### Can I use GitLab Pages if my project is private?

--- a/doc/user/project/pipelines/img/job_artifacts_browser.png
+++ b/doc/user/project/pipelines/img/job_artifacts_browser.png
--- a/doc/user/project/pipelines/img/job_artifacts_browser_button.png
+++ b/doc/user/project/pipelines/img/job_artifacts_browser_button.png
--- a/doc/user/project/pipelines/img/job_artifacts_builds_page.png
+++ b/doc/user/project/pipelines/img/job_artifacts_builds_page.png
--- a/doc/user/project/pipelines/img/job_artifacts_pipelines_page.png
+++ b/doc/user/project/pipelines/img/job_artifacts_pipelines_page.png
--- a/doc/user/project/builds/img/build_latest_artifacts_browser.png
+++ b/doc/user/project/builds/img/build_latest_artifacts_browser.png
--- a/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png
+++ b/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png
--- a/doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png
+++ b/doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png
--- a/doc/user/project/pipelines/job_artifacts.md
+++ b/doc/user/project/pipelines/job_artifacts.md
+# Introduction to job artifacts
+>**Notes:**
+>- Since GitLab 8.2 and GitLab Runner 0.7.0, job artifacts that are created by
+   GitLab Runner are uploaded to GitLab and are downloadable as a single archive
+   (`tar.gz`) using the GitLab UI.
+>- Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
+   changed to `ZIP`, and it is now possible to browse its contents, with the added
+   ability of downloading the files separately.
+>- Starting with GitLab 8.17, builds are renamed to jobs.
+>- The artifacts browser will be available only for new artifacts that are sent
+   to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
+   browse old artifacts already uploaded to GitLab.
+>- This is the user documentation. For the administration guide see
+   [administration/job_artifacts.md](../../../administration/job_artifacts.md).
+Artifacts is a list of files and directories which are attached to a job
+after it completes successfully. This feature is enabled by default in all
+GitLab installations.
+## Defining artifacts in `.gitlab-ci.yml`
+A simple example of using the artifacts definition in `.gitlab-ci.yml` would be
+the following:
+```yaml
+pdf:
+  script: xelatex mycv.tex
+  artifacts:
+    paths:
+    - mycv.pdf
+```
+A job named `pdf` calls the `xelatex` command in order to build a pdf file from
+the latex source file `mycv.tex`. We then define the `artifacts` paths which in
+turn are defined with the `paths` keyword. All paths to files and directories
+are relative to the repository that was cloned during the build.
+For more examples on artifacts, follow the artifacts reference in
+[`.gitlab-ci.yml` documentation](../../../ci/yaml/README.md#artifacts).
+## Browsing job artifacts
+After a job finishes, if you visit the job's specific page, you can see
+that there are two buttons. One is for downloading the artifacts archive and
+the other for browsing its contents.
+![Job artifacts browser button](img/job_artifacts_browser_button.png)
+---
+The archive browser shows the name and the actual file size of each file in the
+archive. If your artifacts contained directories, then you are also able to
+browse inside them.
+Below you can see how browsing looks like. In this case we have browsed inside
+the archive and at this point there is one directory and one HTML file.
+![Job artifacts browser](img/job_artifacts_browser.png)
+---
+## Downloading job artifacts
+If you need to download the whole archive, there are buttons in various places
+inside GitLab that make that possible.
+1. While on the pipelines page, you can see the download icon for each job's
+   artifacts archive in the right corner:
+    ![Job artifacts in Pipelines page](img/job_artifacts_pipelines_page.png)
+1. While on the **Jobs** page, you can see the download icon for each job's
+   artifacts archive in the right corner:
+    ![Job artifacts in Builds page](img/job_artifacts_builds_page.png)
+1. While inside a specific job, you are presented with a download button
+   along with the one that browses the archive:
+    ![Job artifacts browser button](img/job_artifacts_browser_button.png)
+1. And finally, when browsing an archive you can see the download button at
+   the top right corner:
+    ![Job artifacts browser](img/job_artifacts_browser.png)
+## Downloading the latest job artifacts
+It is possible to download the latest artifacts of a job via a well known URL
+so you can use it for scripting purposes.
+The structure of the URL is the following:
+```
+https://example.com/<namespace>/<project>/builds/artifacts/<ref>/download?job=<job_name>
+```
+For example, to download the latest artifacts of the job named `rspec 6 20` of
+the `master` branch of the `gitlab-ce` project that belongs to the `gitlab-org`
+namespace, the URL would be:
+```
+https://gitlab.com/gitlab-org/gitlab-ce/builds/artifacts/master/download?job=rspec+6+20
+```
+The latest builds are also exposed in the UI in various places. Specifically,
+look for the download button in:
+- the main project's page
+- the branches page
+- the tags page
+If the latest job has failed to upload the artifacts, you can see that
+information in the UI.
+![Latest artifacts button](img/job_latest_artifacts_browser.png)
--- a/doc/user/project/pipelines/settings.md
+++ b/doc/user/project/pipelines/settings.md
@@ -35,7 +35,7 @@ if the job surpasses the threshold, it is marked as failed.
 ## Test coverage parsing
 If you use test coverage in your code, GitLab can capture its output in the
-build log using a regular expression. In the pipelines settings, search for the
+job log using a regular expression. In the pipelines settings, search for the
 "Test coverage parsing" section.
 ![Pipelines settings test coverage](img/pipelines_settings_test_coverage.png)
@@ -44,7 +44,7 @@ Leave blank if you want to disable it or enter a ruby regular expression. You
 can use http://rubular.com to test your regex.
 If the pipeline succeeds, the coverage is shown in the merge request widget and
-in the builds table.
+in the jobs table.
 ![MR widget coverage](img/pipelines_test_coverage_mr_widget.png)
@@ -62,9 +62,9 @@ pipelines** checkbox and save the changes.
 ## Badges
-In the pipelines settings page you can find build status and test coverage
+In the pipelines settings page you can find job status and test coverage
 badges for your project. The latest successful pipeline will be used to read
-the build status and test coverage values.
+the job status and test coverage values.
 Visit the pipelines settings page in your project to see the exact link to
 your badges, as well as ways to embed the badge image in your HTML or Markdown
@@ -72,9 +72,9 @@ pages.
 ![Pipelines badges](img/pipelines_settings_badges.png)
-### Build status badge
+### Job status badge
-Depending on the status of your build, a badge can have the following values:
+Depending on the status of your job, a badge can have the following values:
 - running
 - success
@@ -82,7 +82,7 @@ Depending on the status of your build, a badge can have the following values:
 - skipped
 - unknown
-You can access a build status badge image using the following link:
+You can access a job status badge image using the following link:
 ```
 https://example.gitlab.com/<namespace>/<project>/badges/<branch>/build.svg
@@ -91,7 +91,7 @@ https://example.gitlab.com/<namespace>/<project>/badges/<branch>/build.svg
 ### Test coverage report badge
 GitLab makes it possible to define the regular expression for [coverage report],
-that each build log will be matched against. This means that each build in the
+that each job log will be matched against. This means that each job in the
 pipeline can have the test coverage percentage value defined.
 The test coverage badge can be accessed using following link:

--- a/doc/user/project/slash_commands.md
+++ b/doc/user/project/slash_commands.md
@@ -14,7 +14,7 @@ do.
 |:---------------------------|:-------------|
 | `/close`                   | Close the issue or merge request |
 | `/reopen`                  | Reopen the issue or merge request |
-| `/merge`                   | Merge (when build succeeds) |
+| `/merge`                   | Merge (when pipeline succeeds) |
 | `/title <New title>`       | Change title |
 | `/assign @username`        | Assign |
 | `/unassign`                | Remove assignee |

--- a/doc/workflow/shortcuts.md
+++ b/doc/workflow/shortcuts.md
@@ -45,7 +45,7 @@ You can see GitLab's keyboard shortcuts by using 'shift + ?'
 | <kbd>g</kbd> + <kbd>e</kbd> | Go to the project's activity feed |
 | <kbd>g</kbd> + <kbd>f</kbd> | Go to files |
 | <kbd>g</kbd> + <kbd>c</kbd> | Go to commits |
-| <kbd>g</kbd> + <kbd>b</kbd> | Go to builds |
+| <kbd>g</kbd> + <kbd>b</kbd> | Go to jobs |
 | <kbd>g</kbd> + <kbd>n</kbd> | Go to network graph |
 | <kbd>g</kbd> + <kbd>g</kbd> | Go to graphs |
 | <kbd>g</kbd> + <kbd>i</kbd> | Go to issues |

--- a/doc/workflow/todos.md
+++ b/doc/workflow/todos.md
@@ -27,8 +27,8 @@ A Todo appears in your Todos dashboard when:
 - an issue or merge request is assigned to you,
 - you are `@mentioned` in an issue or merge request, be it the description of
  the issue/merge request or in a comment,
- build in the CI pipeline running for your merge request failed, but this
+- a job in the CI pipeline running for your merge request failed, but this
-  build is not allowed to fail.
+  job is not allowed to fail.
 >**Note:** Commenting on a commit will _not_ trigger a Todo.