Update a bunch of docs images

doc/ci/enable_or_disable_ci.md

-## Enable or disable GitLab CI
+## Enable or disable GitLab CI/CD
 
-_To effectively use GitLab CI, you need a valid [`.gitlab-ci.yml`](yaml/README.md)
+To effectively use GitLab CI/CD, you need a valid [`.gitlab-ci.yml`](yaml/README.md)
 file present at the root directory of your project and a
 [runner](runners/README.md) properly set up. You can read our
-[quick start guide](quick_start/README.md) to get you started._
+[quick start guide](quick_start/README.md) to get you started.
 
-If you are using an external CI server like Jenkins or Drone CI, it is advised
-to disable GitLab CI in order to not have any conflicts with the commits status
+If you are using an external CI/CD server like Jenkins or Drone CI, it is advised
+to disable GitLab CI/CD in order to not have any conflicts with the commits status
 API.
 
 ---
 
-GitLab CI is exposed via the `/pipelines` and `/builds` pages of a project.
-Disabling GitLab CI in a project does not delete any previous jobs.
-In fact, the `/pipelines` and `/builds` pages can still be accessed, although
+GitLab CI/CD is exposed via the `/pipelines` and `/jobs` pages of a project.
+Disabling GitLab CI/CD in a project does not delete any previous jobs.
+In fact, the `/pipelines` and `/jobs` pages can still be accessed, although
 it's hidden from the left sidebar menu.
 
-GitLab CI is enabled by default on new installations and can be disabled either
+GitLab CI/CD is enabled by default on new installations and can be disabled either
 individually under each project's settings, or site-wide by modifying the
 settings in `gitlab.yml` and `gitlab.rb` for source and Omnibus installations
 respectively.
 
 ### Per-project user setting
 
-The setting to enable or disable GitLab CI can be found with the name **Pipelines**
-under the **Sharing & Permissions** area of a project's settings along with
-**Merge Requests**. Choose one of **Disabled**, **Only team members** and
-**Everyone with access** and hit **Save changes** for the settings to take effect.
+The setting to enable or disable GitLab CI/CD can be found under your project's
+**Settings > General > Permissions**. Choose one of "Disabled", "Only team members"
+or "Everyone with access" and hit **Save changes** for the settings to take effect.
 
-![Sharing & Permissions settings](img/permissions_settings.png)
+![Sharing & Permissions settings](../user/project/settings/img/sharing_and_permissions_settings.png)
 
----
-
-### Site-wide administrator setting
+### Site-wide admin setting
 
-You can disable GitLab CI site-wide, by modifying the settings in `gitlab.yml`
+You can disable GitLab CI/CD site-wide, by modifying the settings in `gitlab.yml`
 and `gitlab.rb` for source and Omnibus installations respectively.
 
 Two things to note:
 
-1. Disabling GitLab CI, will affect only newly-created projects. Projects that
+1. Disabling GitLab CI/CD, will affect only newly-created projects. Projects that
    had it enabled prior to this modification, will work as before.
-1. Even if you disable GitLab CI, users will still be able to enable it in the
+1. Even if you disable GitLab CI/CD, users will still be able to enable it in the
    project's settings.
 
----
-
 For installations from source, open `gitlab.yml` with your editor and set
 `builds` to `false`:
 

doc/ci/environments.md

@@ -26,7 +26,7 @@ so every environment can have one or more deployments. GitLab keeps track of
 your deployments, so you always know what is currently being deployed on your
 servers. If you have a deployment service such as [Kubernetes][kubernetes-service]
 enabled for your project, you can use it to assist with your deployments, and
-can even access a web terminal for your environment from within GitLab!
+can even access a [web terminal](#web-terminals) for your environment from within GitLab!
 
 To better understand how environments and deployments work, let's consider an
 example. We assume that you have already created a project in GitLab and set up
@@ -119,7 +119,7 @@ where you can find information of the last deployment status of an environment.
 
 Here's how the Environments page looks so far.
 
-![Staging environment view](img/environments_available_staging.png)
+![Environment view](img/environments_available.png)
 
 There's a bunch of information there, specifically you can see:
 
@@ -229,7 +229,7 @@ You can find it in the pipeline, job, environment, and deployment views.
 
 | 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) |
+| ![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_jobs.png) |
 
 Clicking on the play button in either of these places will trigger the
 `deploy_prod` job, and the deployment will be recorded under a new
@@ -402,7 +402,7 @@ places within GitLab.
 
 | In a merge request widget as a link | In the Environments view as a button | In the Deployments view as a button |
 | -------------------- | ------------ | ----------- |
-| ![Environment URL in merge request](img/environments_mr_review_app.png) | ![Environment URL in environments](img/environments_link_url.png) | ![Environment URL in deployments](img/environments_link_url_deployments.png) |
+| ![Environment URL in merge request](img/environments_mr_review_app.png) | ![Environment URL in environments](img/environments_available.png) | ![Environment URL in deployments](img/deployments_view.png) |
 
 If a merge request is eventually merged to the default branch (in our case
 `master`) and that branch also deploys to an environment (in our case `staging`
@@ -574,7 +574,7 @@ Once configured, GitLab will attempt to retrieve [supported performance metrics]
 environment which has had a successful deployment. If monitoring data was
 successfully retrieved, a Monitoring button will appear for each environment.
 
-![Environment Detail with Metrics](img/prometheus_environment_detail_with_metrics.png)
+![Environment Detail with Metrics](img/deployments_view.png)
 
 Clicking on the Monitoring button will display a new page, showing up to the last
 8 hours of performance data. It may take a minute or two for data to appear
@@ -593,10 +593,11 @@ Web terminals were added in GitLab 8.15 and are only available to project
 masters and owners.
 
 If you deploy to your environments with the help of a deployment service (e.g.,
-the [Kubernetes service][kubernetes-service], GitLab can open
+the [Kubernetes service][kubernetes-service]), GitLab can open
 a terminal session to your environment! This is a very powerful feature that
 allows you to debug issues without leaving the comfort of your web browser. To
-enable it, just follow the instructions given in the service documentation.
+enable it, just follow the instructions given in the service integration
+documentation.
 
 Once enabled, your environments will gain a "terminal" button:
 

doc/ci/variables/README.md

@@ -149,14 +149,15 @@ script:
 
 ## Secret variables
 
->**Notes:**
-- This feature requires GitLab Runner 0.4.0 or higher.
-- Group-level secret variables added in GitLab 9.4.
-- Be aware that secret variables are not masked, and their values can be shown
-  in the job logs if explicitly asked to do so. If your project is public or
-  internal, you can set the pipelines private from your project's Pipelines
-  settings. Follow the discussion in issue [#13784][ce-13784] for masking the
-  secret variables.
+NOTE: **Note:**
+Group-level secret variables were added in GitLab 9.4.
+
+CAUTION: **Important:**
+Be aware that secret variables are not masked, and their values can be shown
+in the job logs if explicitly asked to do so. If your project is public or
+internal, you can set the pipelines private from your [project's Pipelines
+settings](../../user/project/pipelines/settings.md#visibility-of-pipelines).
+Follow the discussion in issue [#13784][ce-13784] for masking the secret variables.
 
 GitLab CI allows you to define per-project or per-group secret variables
 that are set in the pipeline environment. The secret variables are stored out of
@@ -171,6 +172,8 @@ Likewise, group-level secret variables can be added by going to your group's
 **Settings > CI/CD**, then finding the section called **Secret variables**.
 Any variables of [subgroups] will be inherited recursively.
 
+![Secret variables](img/secret_variables.png)
+
 Once you set them, they will be available for all subsequent pipelines. You can also
 [protect your variables](#protected-secret-variables).
 
@@ -202,7 +205,7 @@ are set in the build environment. These variables are only defined for
 the project services that you are using to learn which variables they define.
 
 An example project service that defines deployment variables is
-[Kubernetes Service](../../user/project/integrations/kubernetes.md).
+[Kubernetes Service](../../user/project/integrations/kubernetes.md#deployment-variables).
 
 ## Debug tracing
 
@@ -439,7 +442,7 @@ export CI_REGISTRY_USER="gitlab-ci-token"
 export CI_REGISTRY_PASSWORD="longalfanumstring"
 ```
 
-[ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784
+[ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI secret variables"
 [eep]: https://about.gitlab.com/gitlab-ee/ "Available only in GitLab Enterprise Edition Premium"
 [envs]: ../environments.md
 [protected branches]: ../../user/project/protected_branches.md

doc/user/project/container_registry.md

@@ -17,25 +17,25 @@ have its own space to store its Docker images.
 
 You can read more about Docker Registry at https://docs.docker.com/registry/introduction/.
 
----
-
 ## Enable the Container Registry for your project
 
+NOTE: **Note:**
+If you cannot find the Container Registry entry under your project's settings,
+that means that it is not enabled in your GitLab instance. Ask your administrator
+to enable it.
+
 1. First, ask your system administrator to enable GitLab Container Registry
    following the [administration documentation](../../administration/container_registry.md).
    If you are using GitLab.com, this is enabled by default so you can start using
    the Registry immediately.
-
-1. Go to your project's settings and enable the **Container Registry** feature
-   on your project. For new projects this might be enabled by default. For
-   existing projects (prior GitLab 8.8), you will have to explicitly enable it.
-
-    ![Enable Container Registry](img/container_registry_enable.png)
-
+1. Go to your [project's General settings](settings/index.md#sharing-and-permissions)
+   and enable the **Container Registry** feature on your project. For new
+   projects this might be enabled by default. For existing projects
+   (prior GitLab 8.8), you will have to explicitly enable it.
 1. Hit **Save changes** for the changes to take effect. You should now be able
-   to see the **Registry** link in the project menu.
+   to see the **Registry** link in the sidebar.
 
-    ![Container Registry tab](img/container_registry_tab.png)
+![Container Registry](img/container_registry.png)
 
 ## Build and push images
 

doc/user/project/issue_board.md

@@ -12,6 +12,8 @@ Other interesting links:
 - [GitLab Issue Board landing page on about.gitlab.com][landing]
 - [YouTube video introduction to Issue Boards][youtube]
 
+![GitLab Issue Board](img/issue_board.png)
+
 ## Overview
 
 The Issue Board builds on GitLab's existing
@@ -89,10 +91,6 @@ two defaults:
 - **Backlog** (default): shows all open issues that does not belong to one of lists. Always appears on the very left.
 - **Closed** (default): shows all closed issues. Always appears on the very right.
 
-![GitLab Issue Board](img/issue_board.png)
-
----
-
 In short, here's a list of actions you can take in an Issue Board:
 
 - [Create a new list](#creating-a-new-list).

doc/user/project/labels.md

@@ -20,8 +20,6 @@ Head over a single project and navigate to **Issues > Labels**.
 The first time you visit this page, you'll notice that there are no labels
 created yet.
 
-![Generate new labels](img/labels_generate.png)
-
 Creating a new label from scratch is as easy as pressing the **New label**
 button. From there on you can choose the name, give it an optional description,
 a color and you are set.
@@ -32,21 +30,23 @@ When you are ready press the **Create label** button to create the new label.
 
 ---
 
-## Default Labels
-
-It's possible to populate the labels for your project from a set of predefined labels.
-
-### Generate GitLab's predefined label set
+## Default labels
 
-![Generate new labels](img/labels_generate.png)
+The very first time you visit the labels area, it's gonna be empty. In that
+case, it's possible to populate the labels for your project from a set of
+predefined labels.
 
 Click the link to 'Generate a default set of labels' and GitLab will
-generate a set of predefined labels for you. There are 8 default generated labels
-in total and you can see them in the screenshot below.
-
-![Default generated labels](img/labels_default.png)
+generate them for you. There are 8 default generated labels in total:
 
----
+- bug
+- confirmed
+- critical
+- discussion
+- documentation
+- enhancement
+- suggestion
+- support
 
 ## Labels Overview
 
@@ -102,30 +102,25 @@ If you work on a large or popular project, try subscribing only to the labels
 that are relevant to you. You’ll notice it’ll be much easier to focus on what’s
 important.
 
-## Create a new label right from the issue tracker
-
-> Introduced in GitLab 8.6.
+## Create a new label when inside an issue
 
-There are times when you are already in the issue tracker searching for a
+There are times when you are already inside an issue searching to assign a
 label, only to realize it doesn't exist. Instead of going to the **Labels**
 page and being distracted from your original purpose, you can create new
 labels on the fly.
 
-Select **Create new** from the labels dropdown list, provide a name, pick a
-color and hit **Create**.
+Expand the issue sidebar and select **Create new label** from the labels dropdown
+list. Provide a name, pick a color and hit **Create**. The new label will be
+ready to used right away!
 
-![Create new label on the fly](img/labels_new_label_on_the_fly_create.png)
 ![New label on the fly](img/labels_new_label_on_the_fly.png)
 
 ## Assigning labels to issues and merge requests
 
 There are generally two ways to assign a label to an issue or merge request.
 
-You can assign a label when you first create or edit an issue or merge request.
-
-![Assign label in new issue](img/labels_assign_label_in_new_issue.png)
-
----
+The first one is to assign a label when you first create or edit an issue or
+merge request.
 
 The second way is by using the right sidebar when inside an issue or merge
 request. Expand it and hit **Edit** in the labels area. Start typing the name

doc/user/project/merge_requests/cherry_pick_changes.md

@@ -2,24 +2,19 @@
 
 > [Introduced][ce-3514] in GitLab 8.7.
 
----
-
 GitLab implements Git's powerful feature to [cherry-pick any commit][git-cherry-pick]
-with introducing a **Cherry-pick** button in Merge Requests and commit details.
+with introducing a **Cherry-pick** button in merge requests and commit details.
 
-## Cherry-picking a Merge Request
+## Cherry-picking a merge request
 
-After the Merge Request has been merged, a **Cherry-pick** button will be available
-to cherry-pick the changes introduced by that Merge Request:
+After the merge request has been merged, a **Cherry-pick** button will be available
+to cherry-pick the changes introduced by that merge request.
 
 ![Cherry-pick Merge Request](img/cherry_pick_changes_mr.png)
 
----
-
-You can cherry-pick the changes directly into the selected branch or you can opt to
-create a new Merge Request with the cherry-pick changes:
-
-![Cherry-pick Merge Request modal](img/cherry_pick_changes_mr_modal.png)
+After you click that button, a modal will appear where you can choose to
+cherry-pick the changes directly into the selected branch or you can opt to
+create a new merge request with the cherry-pick changes
 
 ## Cherry-picking a Commit
 
@@ -27,15 +22,9 @@ You can cherry-pick a Commit from the Commit details page:
 
 ![Cherry-pick commit](img/cherry_pick_changes_commit.png)
 
----
-
-Similar to cherry-picking a Merge Request, you can opt to cherry-pick the changes
-directly into the target branch or create a new Merge Request to cherry-pick the
-changes:
-
-![Cherry-pick commit modal](img/cherry_pick_changes_commit_modal.png)
-
----
+Similar to cherry-picking a merge request, you can opt to cherry-pick the changes
+directly into the target branch or create a new merge request to cherry-pick the
+changes.
 
 Please note that when cherry-picking merge commits, the mainline will always be the
 first parent. If you want to use a different mainline then you need to do that

doc/user/project/merge_requests/index.md

@@ -3,6 +3,8 @@
 Merge requests allow you to exchange changes you made to source code and
 collaborate with other people on the same project.
 
+![Merge request view](img/merge_request.png)
+
 ## Overview
 
 A Merge Request (**MR**) is the basis of GitLab as a code collaboration

doc/user/project/merge_requests/revert_changes.md

@@ -2,51 +2,39 @@
 
 > [Introduced][ce-1990] in GitLab 8.5.
 
----
-
 GitLab implements Git's powerful feature to [revert any commit][git-revert]
-with introducing a **Revert** button in Merge Requests and commit details.
+with introducing a **Revert** button in merge requests and commit details.
 
 ## Reverting a Merge Request
 
-_**Note:** The **Revert** button will only be available for Merge Requests
-created since GitLab 8.5. However, you can still revert a Merge Request
-by reverting the merge commit from the list of Commits page._
+NOTE: **Note:**
+The **Revert** button will only be available for merge requests
+created since GitLab 8.5. However, you can still revert a merge request
+by reverting the merge commit from the list of Commits page.
 
 After the Merge Request has been merged, a **Revert** button will be available
-to revert the changes introduced by that Merge Request:
-
-![Revert Merge Request](img/revert_changes_mr.png)
-
----
-
-You can revert the changes directly into the selected branch or you can opt to
-create a new Merge Request with the revert changes:
+to revert the changes introduced by that merge request.
 
-![Revert Merge Request modal](img/revert_changes_mr_modal.png)
+![Revert Merge Request](img/cherry_pick_changes_mr.png)
 
----
+After you click that button, a modal will appear where you can choose to
+revert the changes directly into the selected branch or you can opt to
+create a new merge request with the revert changes.
 
-After the Merge Request has been reverted, the **Revert** button will not be
+After the merge request has been reverted, the **Revert** button will not be
 available anymore.
 
 ## Reverting a Commit
 
 You can revert a Commit from the Commit details page:
 
-![Revert commit](img/revert_changes_commit.png)
-
----
-
-Similar to reverting a Merge Request, you can opt to revert the changes
-directly into the target branch or create a new Merge Request to revert the
-changes:
-
-![Revert commit modal](img/revert_changes_commit_modal.png)
+![Revert commit](img/cherry_pick_changes_commit.png)
 
----
+Similar to reverting a merge request, you can opt to revert the changes
+directly into the target branch or create a new merge request to revert the
+changes.
 
-After the Commit has been reverted, the **Revert** button will not be available
+After the commit has been reverted, the **Revert** button will not be available
 anymore.
 
 Please note that when reverting merge commits, the mainline will always be the