UI changes and renamed section required changes

doc/ci/chatops/README.md

@@ -10,7 +10,7 @@ GitLab ChatOps provides a method to interact with CI/CD jobs through chat servic
 
 ## How it works
 
-GitLab ChatOps is built upon two existing features, [GitLab CI/CD](../README.md) and [Slack Slash Commmands](../../user/project/integrations/slack_slash_commands.md). 
+GitLab ChatOps is built upon two existing features, [GitLab CI/CD](../README.md) and [Slack Slash Commmands](../../user/project/integrations/slack_slash_commands.md).
 
 A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [.gitlab-ci.yml](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.html#predefined-variables-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
 
@@ -22,9 +22,9 @@ After the job has finished, its output is sent back to Slack provided it has com
 
 Since ChatOps is built upon GitLab CI/CD, the job has all the same features and functions available. There a few best practices to consider however when creating ChatOps jobs:
 
-* It is strongly recommended to set `only: [chat]` so the job does not run as part of the standard CI pipeline. 
-* If the job is set to `when: manual`, the pipeline will be created however the job will wait to be started. 
-* It is important to keep in mind that there is very limited support for access control. If the user who triggered the slash command is a developer in the project, the job will run. The job itself can utilize existing [CI/CD variables](../variables/README.html#predefined-variables-environment-variables) like `GITLAB_USER_ID` to perform additional rights validation, however these variables can be [overridden](https://docs.gitlab.com/ce/ci/variables/README.html#priority-of-variables).
+* It is strongly recommended to set `only: [chat]` so the job does not run as part of the standard CI pipeline.
+* If the job is set to `when: manual`, the pipeline will be created however the job will wait to be started.
+* It is important to keep in mind that there is very limited support for access control. If the user who triggered the slash command is a developer in the project, the job will run. The job itself can utilize existing [CI/CD variables](../variables/README.html#predefined-environment-variables) like `GITLAB_USER_ID` to perform additional rights validation, however these variables can be [overridden](https://docs.gitlab.com/ce/ci/variables/README.html#priority-of-variables).
 
 ### Controlling the ChatOps reply
 
@@ -53,7 +53,7 @@ ls:
 
 ## GitLab ChatOps icon
 
-Say Hi to our ChatOps bot.  
+Say Hi to our ChatOps bot.
 You can find and download the official GitLab ChatOps icon here.
 
 ![GitLab ChatOps bot icon](img/gitlab-chatops-icon-small.png)

doc/ci/ci_cd_for_external_repos/bitbucket_integration.md

@@ -10,7 +10,7 @@ your Git repository via URL.
     ![Create project](img/external_repository.png)
 
     GitLab will import the repository and enable [Pull Mirroring][pull-mirroring].
-    
+
 1. In GitLab create a
    [Personal Access Token](../../user/profile/personal_access_tokens.md)
    with `api` scope. This will be used to authenticate requests from the web
@@ -39,7 +39,7 @@ your Git repository via URL.
 
     ![Bitbucket Cloud webhook](img/bitbucket_app_password.png)
 
-1. In GitLab from **Settings > CI/CD > Variables** add variables to allow
+1. In GitLab from **Settings > CI/CD > Environment variables** add variables to allow
    communication with Bitbucket via the Bitbucket API.
 
     `BITBUCKET_ACCESS_TOKEN`: the Bitbucket app password created above

doc/user/project/clusters/kubernetes_pod_logs.md

@@ -24,7 +24,7 @@ There are a few key requirements in order to be able to use Pod Logs:
 1. A GitLab Runner. If one is not available, they can be easily [deployed](index.md#installing-applications).
 1. Ensure a Kubernetes label of `app: $CI_ENVIRONMENT_SLUG` is applied to the
    deployments, replica sets, and pods, where `$CI_ENVIRONMENT_SLUG` is the value
-   of the [CI variable](../../../ci/variables/README.md#predefined-variables-environment-variables).
+   of the [CI variable](../../../ci/variables/README.md#predefined-environment-variables).
    This needed to determine the environment a pod belongs to
    when is more than one. These resources should be
    contained in the namespace defined in the Kubernetes service setting.

doc/user/project/packages/maven_repository.md

@@ -337,4 +337,4 @@ shows how to create a new package each time the `master` branch is updated:
 The next time the `deploy` job runs, it will copy `ci_settings.xml` to the
 user's home location (in this case the user is `root` since it runs in a
 Docker container), and Maven will utilize the configured CI
-[environment variables](../../../ci/variables/README.md#predefined-variables-environment-variables).
+[environment variables](../../../ci/variables/README.md#predefined-environment-variables).