Improve capitalization and backticks in ci docs

Clean up capitalization of product names, as well
as improve backtick use in /ci docs

doc/ci/README.md

@@ -113,7 +113,7 @@ Its feature set is listed on the table below according to DevOps stages.
 | [Browser Performance Testing](../user/project/merge_requests/browser_performance_testing.md) | Quickly determine the performance impact of pending code changes. |
 | [CI services](services/README.md) | Link Docker containers with your base image.|
 | [Code Quality](../user/project/merge_requests/code_quality.md) **(STARTER)** | Analyze your source code quality. |
-| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md) **(PREMIUM)** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and BitBucket Cloud. |
+| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md) **(PREMIUM)** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and Bitbucket Cloud. |
 | [Interactive Web Terminals](interactive_web_terminal/index.md) **(CORE ONLY)** | Open an interactive web terminal to debug the running jobs. |
 | [JUnit tests](junit_test_reports.md) | Identify script failures directly on merge requests. |
 | [Using Docker images](docker/using_docker_images.md) | Use GitLab and GitLab Runner with Docker to build and test applications. |

doc/ci/caching/index.md

@@ -202,7 +202,7 @@ For more fine tuning, read also about the
 
 The most common use case of cache is to preserve contents between subsequent
 runs of jobs for things like dependencies and commonly used libraries
-(Nodejs packages, PHP packages, rubygems, python libraries, etc.),
+(Nodejs packages, PHP packages, rubygems, Python libraries, etc.),
 so they don't have to be re-fetched from the public internet.
 
 NOTE: **Note:**
@@ -268,7 +268,7 @@ test:
 ### Caching Python dependencies
 
 Assuming your project is using [pip](https://pip.pypa.io/en/stable/) to install
-the python dependencies, the following example defines `cache` globally so that
+the Python dependencies, the following example defines `cache` globally so that
 all jobs inherit it. Python libraries are installed in a virtualenv under `venv/`,
 pip's cache is defined under `.cache/pip/` and both are cached per-branch:
 

doc/ci/chatops/README.md

@@ -19,7 +19,7 @@ GitLab ChatOps is built upon two existing features:
 - [GitLab CI/CD](../README.md).
 - [Slack Slash Commands](../../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.md#predefined-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.
+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.md#predefined-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.
 
 After the job has finished, its output is sent back to Slack provided it has completed within 30 minutes. If a job takes more than 30 minutes to run it must use the Slack API to manually send data back to a channel.
 

doc/ci/directed_acyclic_graph/index.md

@@ -73,4 +73,4 @@ A directed acyclic graph is a complicated feature, and as of the initial MVC the
 are certain use cases that you may need to work around. For more information:
 
 - [`needs` requirements and limitations](../yaml/README.md#requirements-and-limitations).
-- Related epic [gitlab-org#1716](https://gitlab.com/groups/gitlab-org/-/epics/1716).
+- Related epic [#1716](https://gitlab.com/groups/gitlab-org/-/epics/1716).

doc/ci/docker/using_docker_build.md

@@ -526,7 +526,7 @@ Some things you should be aware of:
   longer, but means you don’t get stuck without security patches to base images.
 - Doing an explicit `docker pull` before each `docker run` fetches
   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
+  using multiple runners that cache images locally. Using the Git SHA in your
   image tag makes this less necessary since each job will be unique and you
   shouldn't ever have a stale image. However, it's still possible to have a
   stale image if you re-build a given commit after a dependency has changed.

doc/ci/environments.md

@@ -679,7 +679,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 ### Scoping environments with specs
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
-> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) to Core in Gitlab 12.2.
+> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) to Core in GitLab 12.2.
 
 You can limit the environment scope of a variable by
 defining which environments it can be available for.

doc/ci/examples/README.md

@@ -13,7 +13,7 @@ Examples are available in several forms. As a collection of:
 - `.gitlab-ci.yml` [template files](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates) maintained in GitLab. When you create a new file via the UI,
   GitLab will give you the option to choose one of these templates. This will allow you to quickly bootstrap your project for CI/CD.
   If your favorite programming language or framework are missing, we would love your help by sending a merge request with a new `.gitlab-ci.yml` to this project.
-- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by nginx](https://gitlab.com/gitlab-examples/review-apps-nginx/).
+- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
 - Examples and [other resources](#other-resources) listed below.
 
 ## CI/CD examples

doc/ci/examples/deployment/README.md

@@ -46,7 +46,7 @@ staging:
   - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
 ```
 
-In the above example we use Dpl to deploy `my-app-staging` to Heroku server with api-key stored in `HEROKU_STAGING_API_KEY` secure variable.
+In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
 
 To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
 

doc/ci/examples/deployment/composer-npm-deploy.md

@@ -46,7 +46,7 @@ All these operations will put all files into a `build` folder, which is ready to
 
 You have multiple options: rsync, scp, sftp and so on. For now, we will use scp.
 
-To make this work, you need to add a GitLab CI/CD Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** ssh key of your server.
+To make this work, you need to add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** SSH key of your server.
 
 ### Security tip
 
@@ -98,7 +98,7 @@ Here's the breakdown:
 1. We will connect via `ssh` and create a new `_tmp` folder
 1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
 1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
-1. We connect to ssh and remove the `_old` folder
+1. We connect to SSH and remove the `_old` folder
 
 What's the deal with the artifacts? We just tell GitLab CI to keep the `build` directory (later on, you can download that as needed).
 

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -28,7 +28,7 @@ layers of your application, from the frontend to the database.
 In this article, we will discuss how
 to write such end-to-end tests, and how to set up GitLab CI/CD to automatically run these tests
 against your new code, on a branch-by-branch basis. For the scope of this article, we will walk you
-through the process of setting up GitLab CI/CD for end-to-end testing Javascript-based applications
+through the process of setting up GitLab CI/CD for end-to-end testing JavaScript-based applications
 with WebdriverIO, but the general strategy should carry over to other languages.
 We assume you are familiar with GitLab, [GitLab CI/CD](../../README.md), [Review Apps](../../review_apps/index.md), and running your app locally, e.g., on `localhost:8000`.
 
@@ -47,7 +47,7 @@ infrastructure is up and running, and that your units of code work well together
 [Selenium](http://www.seleniumhq.org/) is a piece of software that can control web browsers, e.g., to make them
 visit a specific URL or interact with elements on the page. It can be programmatically controlled
 from a variety of programming languages. In this article we're going to be using the
-[WebdriverIO](http://webdriver.io/) Javascript bindings, but the general concept should carry over
+[WebdriverIO](http://webdriver.io/) JavaScript bindings, but the general concept should carry over
 pretty well to
 [other programming languages supported by Selenium](http://docs.seleniumhq.org/about/platforms.jsp#programming-languages).
 

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -82,7 +82,7 @@ git push -u origin master
 ## Configure the production server
 
 Before we begin setting up Envoy and GitLab CI/CD, let's quickly make sure the production server is ready for deployment.
-We have installed LEMP stack which stands for Linux, Nginx, MySQL and PHP on our Ubuntu 16.04.
+We have installed LEMP stack which stands for Linux, NGINX, MySQL and PHP on our Ubuntu 16.04.
 
 ### Create a new user
 
@@ -151,11 +151,11 @@ git clone git@gitlab.example.com:<USERNAME>/laravel-sample.git
 Answer **yes** if asked `Are you sure you want to continue connecting (yes/no)?`.
 It adds GitLab.com to the known hosts.
 
-### Configuring Nginx
+### Configuring NGINX
 
 Now, let's make sure our web server configuration points to the `current/public` rather than `public`.
 
-Open the default Nginx server block configuration file by typing:
+Open the default NGINX server block configuration file by typing:
 
 ```bash
 sudo nano /etc/nginx/sites-available/default

doc/ci/examples/test-and-deploy-python-application-to-heroku.md

@@ -86,6 +86,6 @@ gitlab-runner register \
   --docker-postgres latest
 ```
 
-With the command above, you create a runner that uses the [python:3.5](https://hub.docker.com/r/_/python/) image and uses a [postgres](https://hub.docker.com/r/_/postgres/) database.
+With the command above, you create a runner that uses the [`python:3.5`](https://hub.docker.com/r/_/python/) image and uses a [PostgreSQL](https://hub.docker.com/r/_/postgres/) database.
 
 To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -205,7 +205,7 @@ when running our Phoenix in our `localhost`.
 
   As our project is still fresh, we don't have any data on our database, so, the `migrations`
   directory will be empty.
-  Without `.gitkeep`, git will not upload this empty directory and we'll got an error when running our
+  Without `.gitkeep`, Git will not upload this empty directory and we'll got an error when running our
   test on GitLab.
 
   > **Note:** If we add a folder via the GitLab UI, GitLab itself will add the `.gitkeep` to that new dir.

doc/ci/interactive_web_terminal/index.md

@@ -30,7 +30,7 @@ Two things need to be configured for the interactive web terminal to work:
 
 NOTE: **Note:**
 Interactive web terminals are not yet supported by
-[`gitlab-runner` helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
+[`gitlab-runner` Helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
 but support [is planned](https://gitlab.com/gitlab-org/charts/gitlab-runner/issues/79).
 
 ## Debugging a running job

doc/ci/jenkins/index.md

@@ -202,7 +202,7 @@ can provide any variables they like.
 
 #### `triggers` / `cron`
 
-Because GitLab is integrated tightly with git, SCM polling options for triggers are not needed. We support an easy to use
+Because GitLab is integrated tightly with Git, SCM polling options for triggers are not needed. We support an easy to use
 [syntax for scheduling pipelines](../../user/project/pipelines/schedules.md).
 
 #### `tools`

doc/ci/large_repositories/index.md

@@ -111,7 +111,7 @@ machines, and have an existing worktree that you can re-use for builds.
 
 For exact parameters accepted by
 [`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
-for [git clean](https://git-scm.com/docs/git-clean). The available parameters
+for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
 are dependent on Git version.
 
 ## Fork-based workflow

doc/ci/quick_start/README.md

@@ -22,7 +22,7 @@ GitLab offers a [continuous integration][ci] service. If you
 and configure your GitLab project to use a [Runner], then each commit or
 push triggers your CI [pipeline].
 
-The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs
+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
 use all three stages; stages with no jobs are simply ignored.
 
@@ -126,7 +126,7 @@ a "CI Lint" button to go to this page under **CI/CD ➔ Pipelines** and
 **Pipelines ➔ Jobs** in your project.
 
 For more information and a complete `.gitlab-ci.yml` syntax, please read
-[the reference documentation on .gitlab-ci.yml](../yaml/README.md).
+[the reference documentation on `.gitlab-ci.yml`](../yaml/README.md).
 
 ### Push `.gitlab-ci.yml` to GitLab
 

doc/ci/ssh_keys/README.md

@@ -25,10 +25,10 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
 
 ## How it works
 
-1. Create a new SSH key pair locally with [ssh-keygen](http://linux.die.net/man/1/ssh-keygen)
+1. Create a new SSH key pair locally with [`ssh-keygen`](http://linux.die.net/man/1/ssh-keygen)
 1. Add the private key as a [variable](../variables/README.md) to
    your project
-1. Run the [ssh-agent](http://linux.die.net/man/1/ssh-agent) during job to load
+1. Run the [`ssh-agent`](http://linux.die.net/man/1/ssh-agent) during job to load
    the private key.
 1. Copy the public key to the servers you want to have access to (usually in
    `~/.ssh/authorized_keys`) or add it as a [deploy key](../../ssh/README.md#deploy-keys)

doc/ci/variables/predefined_variables.md

@@ -108,7 +108,7 @@ future GitLab releases.**
 | `CI_RUNNER_VERSION`                     | all    | 10.6   | GitLab Runner version that is executing the current job |
 | `CI_RUNNER_SHORT_TOKEN`                 | all    | 12.3   | First eight characters of GitLab Runner's token used to authenticate new job requests. Used as Runner's unique ID |
 | `CI_SERVER`                             | all    | all    | Mark that job is executed in CI environment |
-| `CI_SERVER_HOST`                        | 12.1   | all    | Host component of the GitLab instance URL, without protocol and port (like gitlab.example.com) |
+| `CI_SERVER_HOST`                        | 12.1   | all    | Host component of the GitLab instance URL, without protocol and port (like `gitlab.example.com`) |
 | `CI_SERVER_NAME`                        | all    | all    | The name of CI server that is used to coordinate jobs |
 | `CI_SERVER_REVISION`                    | all    | all    | GitLab revision that is used to schedule jobs |
 | `CI_SERVER_VERSION`                     | all    | all    | GitLab version that is used to schedule jobs |

doc/ci/yaml/README.md

@@ -56,7 +56,7 @@ Jobs are picked up 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.
 
-### Validate the .gitlab-ci.yml
+### Validate the `.gitlab-ci.yml`
 
 Each instance of GitLab CI has an embedded debug tool called Lint, which validates the
 content of your `.gitlab-ci.yml` files. You can find the Lint under the page `ci/lint` of your
@@ -187,7 +187,7 @@ Used to specify [a Docker image](../docker/using_docker_images.md#what-is-an-ima
 
 For:
 
-- Simple definition examples, see [Define `image` and `services` from .gitlab-ci.yml](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
+- Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
 - Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
 
 #### `image:name`
@@ -208,7 +208,7 @@ Used to specify a [service Docker image](../docker/using_docker_images.md#what-i
 
 For:
 
-- Simple definition examples, see [Define `image` and `services` from .gitlab-ci.yml](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
+- Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
 - Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
 - For example services, see [GitLab CI Services](../services/README.md).
 
@@ -379,8 +379,8 @@ In addition, `only` and `except` allow the use of special keywords:
 
 | **Value** |  **Description**  |
 | --------- |  ---------------- |
-| `branches`       | When a git reference of a pipeline is a branch.  |
-| `tags`           | When a git reference of a pipeline is a tag.  |
+| `branches`       | When a Git reference of a pipeline is a branch.  |
+| `tags`           | When a Git reference of a pipeline is a tag.  |
 | `api`            | When pipeline has been triggered by a second pipelines API (not triggers API).  |
 | `external`       | When using CI services other than GitLab. |
 | `pipelines`      | For multi-project triggers, created using the API with `CI_JOB_TOKEN`. |
@@ -530,15 +530,15 @@ single conjoined expression. That is:
 
 With `only`, individual keys are logically joined by an AND:
 
-> (any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active)
+> (any of refs) AND (any of variables) AND (any of changes) AND (if Kubernetes is active)
 
 `except` is implemented as a negation of this complete expression:
 
-> NOT((any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active))
+> NOT((any of refs) AND (any of variables) AND (any of changes) AND (if Kubernetes is active))
 
 This, more intuitively, means the keys join by an OR. A functionally equivalent expression:
 
-> (any of refs) OR (any of variables) OR (any of changes) OR (if kubernetes is active)
+> (any of refs) OR (any of variables) OR (any of changes) OR (if Kubernetes is active)
 
 #### `only:refs`/`except:refs`
 
@@ -612,7 +612,7 @@ Learn more about [variables expressions](../variables/README.md#environment-vari
 > `changes` policy [introduced][ce-19232] in GitLab 11.4.
 
 Using the `changes` keyword with `only` or `except` makes it possible to define if
-a job should be created based on files modified by a git push event.
+a job should be created based on files modified by a Git push event.
 
 For example:
 
@@ -1047,7 +1047,7 @@ You can stop the active timer of a delayed job by clicking the **Unschedule** bu
 This job will never be executed in the future unless you execute the job manually.
 
 You can start a delayed job immediately by clicking the **Play** button.
-GitLab runner will pick your job soon and start the job.
+GitLab Runner will pick your job soon and start the job.
 
 ### `environment`
 
@@ -1894,12 +1894,12 @@ This example creates three paths of execution:
     - 50 if the `ci_dag_limit_needs` feature flag is disabled.
 - It is impossible for now to have `needs: []` (empty needs),
   the job always needs to depend on something, unless this is the job
-  in the first stage (see [gitlab-foss#65504](https://gitlab.com/gitlab-org/gitlab-foss/issues/65504)).
+  in the first stage (see [issue #65504](https://gitlab.com/gitlab-org/gitlab-foss/issues/65504)).
 - If `needs:` refers to a job that is marked as `parallel:`.
   the current job will depend on all parallel jobs created.
 - `needs:` is similar to `dependencies:` in that it needs to use jobs from
   prior stages, meaning it is impossible to create circular
-  dependencies or depend on jobs in the current stage (see [gitlab-foss#65505](https://gitlab.com/gitlab-org/gitlab-foss/issues/65505)).
+  dependencies or depend on jobs in the current stage (see [issue #65505](https://gitlab.com/gitlab-org/gitlab-foss/issues/65505)).
 - Related to the above, stages must be explicitly defined for all jobs
   that have the keyword `needs:` or are referred to by one.
 
@@ -2831,7 +2831,7 @@ The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
 `git clean` after checking out the sources. You can set it globally or per-job in the
 [`variables`](#variables) section.
 
-`GIT_CLEAN_FLAGS` accepts all possible options of the [git clean](https://git-scm.com/docs/git-clean)
+`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
 command.
 
 `git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
@@ -2946,7 +2946,7 @@ default:
 
 ## Custom build directories
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267) in Gitlab Runner 11.10
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267) in GitLab Runner 11.10
 
 NOTE: **Note:**
 This can only be used when `custom_build_dir` is enabled in the [Runner's