Add latest changes from gitlab-org/gitlab@master

.gitlab/ci/reports.gitlab-ci.yml

@@ -198,6 +198,7 @@ dast:
     - .only-code-qa-changes
     - .only-review
   stage: qa
+  needs: ["review-deploy"]
   dependencies: ["review-deploy"]
   before_script:
     - export DAST_WEBSITE="$(cat review_app_url.txt)"

.gitlab/ci/review.gitlab-ci.yml

@@ -183,6 +183,7 @@ review-cleanup-failed-deployment:
     GITLAB_ADMIN_PASSWORD: "${REVIEW_APPS_ROOT_PASSWORD}"
     GITHUB_ACCESS_TOKEN: "${REVIEW_APPS_QA_GITHUB_ACCESS_TOKEN}"
     EE_LICENSE: "${REVIEW_APPS_EE_LICENSE}"
+  needs: ["review-deploy"]
   dependencies: ["review-deploy"]
   artifacts:
     paths:
@@ -239,6 +240,8 @@ review-performance:
   extends:
     - .review-performance-base
     - .only-review
+  needs: ["review-deploy"]
+  dependencies: ["review-deploy"]
   before_script:
     - export CI_ENVIRONMENT_URL="$(cat review_app_url.txt)"
     - echo "${CI_ENVIRONMENT_URL}"
@@ -259,6 +262,7 @@ schedule:review-performance:
   extends:
     - .review-performance-base
     - .only-review-schedules
+  needs: ["schedule:review-deploy"]
   dependencies: ["schedule:review-deploy"]
 parallel-spec-reports:

CHANGELOG.md

@@ -641,13 +641,6 @@ entry.
 - Update Packer.gitlab-ci.yml to use latest image. (Kelly Hair)
-## 12.1.13
-
-### Security (1 change)
-
-- Fix private feature Elasticsearch leak.
-
-
 ## 12.1.12
 ### Security (12 changes)

changelogs/unreleased/32397-geo-instructions-to-update-fdw-schema-aren-t-entirely-correct.yml

+---
+title: 'Geo: Fix instruction from rake geo:gitlab:check'
+merge_request: 17895
+author:
+type: changed

doc/ci/examples/README.md

@@ -11,7 +11,7 @@ implement [GitLab CI/CD](../README.md) for your specific use case.
 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.
+  GitLab will give you the option to choose one of these templates. This will allow you to start using CI/CD with your project quickly.
   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/).
 - Examples and [other resources](#other-resources) listed below.

doc/development/pipelines.md

@@ -185,11 +185,11 @@ subgraph "`qa` stage"
     R --> |needs| F;
     P --> |needs| B;
     P --> |needs| F;
-    review-qa-smoke -.-> |depends on| G;
-    review-qa-all -.-> |depends on| G;
-    review-qa-performance -.-> |depends on| G;
-    X2["schedule:review-performance<br/>(master only)"] -.-> |depends on| G2;
-    dast -.-> |depends on| G;
+    review-qa-smoke -.-> |needs and depends on| G;
+    review-qa-all -.-> |needs and depends on| G;
+    review-performance -.-> |needs and depends on| G;
+    X2["schedule:review-performance<br/>(master only)"] -.-> |needs and depends on| G2;
+    dast -.-> |needs and depends on| G;
     end
 subgraph "`notification` stage"

doc/gitlab-basics/create-project.md

@@ -83,8 +83,8 @@ You can improve the existing built-in templates or contribute new ones in the
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6860) in
 [GitLab Premium](https://about.gitlab.com/pricing) 11.2.
-Creating new projects based on custom project templates is a convenient option to
-bootstrap a project.
+Creating new projects based on custom project templates is a convenient option for
+quickly starting projects.
 Custom projects are available at the [instance-level](../user/admin_area/custom_project_templates.md)
 from the **Instance** tab, or at the [group-level](../user/group/custom_project_templates.md)

doc/install/aws/index.md

@@ -112,12 +112,12 @@ RDS instances as well:
 1. Follow the same steps to create all subnets:
-   | Name tag | Type |Availability Zone | CIDR block |
-   | -------- | ---- | ---------------- | ---------- |
-   | gitlab-public-10.0.0.0  | public  | us-west-2a | 10.0.0.0 |
-   | gitlab-private-10.0.1.0 | private | us-west-2a | 10.0.1.0 |
-   | gitlab-public-10.0.2.0  | public  | us-west-2b | 10.0.2.0 |
-   | gitlab-private-10.0.3.0 | private | us-west-2b | 10.0.3.0 |
+   | Name tag                  | Type    | Availability Zone | CIDR block |
+   | ------------------------- | ------- | ----------------- | ---------- |
+   | `gitlab-public-10.0.0.0`  | public  | `us-west-2a`      | `10.0.0.0` |
+   | `gitlab-private-10.0.1.0` | private | `us-west-2a`      | `10.0.1.0` |
+   | `gitlab-public-10.0.2.0`  | public  | `us-west-2b`      | `10.0.2.0` |
+   | `gitlab-private-10.0.3.0` | private | `us-west-2b`      | `10.0.3.0` |
 ### Route Table
@@ -231,7 +231,7 @@ Now, it's time to create the database:
    and a master password. We've chosen to use `gitlab-db-ha`, `gitlab` and a
    very secure password respectively. Keep these in hand for later.
 1. Click **Next** to proceed to the advanced settings.
-1. Make sure to choose our gitlab VPC, our subnet group, set public accessibility to
+1. Make sure to choose our GitLab VPC, our subnet group, set public accessibility to
    **No**, and to leave it to create a new security group. The only additional
    change which will be helpful is the database name for which we can use
    `gitlabhq_production`. At the very bottom, there's an option to enable

doc/install/azure/index.md

@@ -28,8 +28,8 @@ First, you'll need an account on Azure. There are three ways to do this:
 ## Working with Azure
-Once you have an Azure account, you can get started. Login to Azure using
-[portal.azure.com](https://portal.azure.com) and the first thing you will see is the Dashboard:
+Once you have an Azure account, you can get started. [Log in to Azure](https://portal.azure.com)
+and the first thing you will see is the Dashboard:
 ![Azure Dashboard](img/azure-dashboard.png)
@@ -64,7 +64,7 @@ The first items we need to configure are the basic settings of the underlying vi
 1. Enter a `Name` for the VM - e.g. **"GitLab-CE"**
 1. Select a `VM disk type` - either **HDD** _(slower, lower cost)_ or **SSD** _(faster, higher cost)_
-1. Enter a `User name` - e.g. **"gitlab-admin"**
+1. Enter a `User name` - e.g. `gitlab-admin`
 1. Select an `Authentication type`, either **SSH public key** or **Password**:
    > **Note:** if you're unsure which authentication type to use, select **Password**
@@ -167,7 +167,7 @@ in the `DNS name label` field:
 ![Azure - VM - Domain Name](img/azure-vm-domain-name.png)
-In the screenshot above, you'll see that we've set the `DNS name label` to **"gitlab-ce-test"**.
+In the screenshot above, you'll see that we've set the `DNS name label` to `gitlab-ce-test`.
 This will make our VM accessible at `gitlab-ce-test.centralus.cloudapp.azure.com`
 _(the full domain name of your own VM will be different, of course)_.
@@ -397,7 +397,7 @@ is now showing **"up-to-date"**:
 ## Conclusion
-Naturally, we believe that GitLab is a great git repository tool. However, GitLab is a whole lot
+Naturally, we believe that GitLab is a great Git repository tool. However, GitLab is a whole lot
 more than that too. GitLab unifies issues, code review, CI and CD into a single UI, helping you to
 move faster from idea to production, and in this tutorial we showed you how quick and easy it is to
 set up and run your own instance of GitLab on Azure, Microsoft's cloud service.

doc/install/installation.md

@@ -27,12 +27,12 @@ following the
 Since an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/install/) (deb/rpm).
-One reason the Omnibus package is more reliable is its use of Runit to restart any of the GitLab processes in case one crashes.
+One reason the Omnibus package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes.
 On heavily used GitLab instances the memory usage of the Sidekiq background worker will grow over time.
 Omnibus packages solve this by [letting the Sidekiq terminate gracefully](../administration/operations/sidekiq_memory_killer.md) if it uses too much memory.
-After this termination Runit will detect Sidekiq is not running and will start it.
-Since installations from source don't use Runit for process supervision, Sidekiq
+After this termination runit will detect Sidekiq is not running and will start it.
+Since installations from source don't use runit for process supervision, Sidekiq
 can't be terminated and its memory usage will grow over time.
 ## Select version to install
@@ -84,7 +84,7 @@ The GitLab installation consists of setting up the following components:
 1. [Database](#6-database).
 1. [Redis](#7-redis).
 1. [GitLab](#8-gitlab).
-1. [Nginx](#9-nginx).
+1. [NGINX](#9-nginx).
 ## 1. Packages and dependencies
@@ -588,7 +588,7 @@ You can specify a different Git repository by providing it as an extra parameter
 sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse,https://example.com/gitlab-workhorse.git]" RAILS_ENV=production
 ```
-### Install gitlab-elasticsearch-indexer
+### Install GitLab-Elasticsearch-indexer`
 GitLab-Elasticsearch-Indexer uses [GNU Make](https://www.gnu.org/software/make/). The
 following command-line will install GitLab-Elasticsearch-Indexer in `/home/git/gitlab-elasticsearch-indexer`
@@ -646,7 +646,7 @@ sudo -u git -H editor config.toml
 ```
 For more information about configuring Gitaly see
-[doc/administration/gitaly](../administration/gitaly).
+[the Gitaly documentation](../administration/gitaly/index.md).
 ### Start Gitaly
@@ -749,10 +749,10 @@ sudo service gitlab start
 sudo /etc/init.d/gitlab restart
 ```
-## 9. Nginx
+## 9. NGINX
 NOTE: **Note:**
-Nginx is the officially supported web server for GitLab. If you cannot or do not want to use Nginx as your web server, see [GitLab recipes](https://gitlab.com/gitlab-org/gitlab-recipes/).
+NGINX is the officially supported web server for GitLab. If you cannot or do not want to use NGINX as your web server, see [GitLab recipes](https://gitlab.com/gitlab-org/gitlab-recipes/).
 ### Installation
@@ -784,21 +784,21 @@ Make sure to edit the config file to match your setup. Also, ensure that you mat
 sudo editor /etc/nginx/sites-available/gitlab
 ```
-If you intend to enable GitLab pages, there is a separate Nginx config you need
+If you intend to enable GitLab Pages, there is a separate NGINX config you need
 to use. Read all about the needed configuration at the
 [GitLab Pages administration guide](../administration/pages/index.md).
-**Note:** If you want to use HTTPS, replace the `gitlab` Nginx config with `gitlab-ssl`. See [Using HTTPS](#using-https) for HTTPS configuration details.
+**Note:** If you want to use HTTPS, replace the `gitlab` NGINX config with `gitlab-ssl`. See [Using HTTPS](#using-https) for HTTPS configuration details.
 ### Test Configuration
-Validate your `gitlab` or `gitlab-ssl` Nginx config file with the following command:
+Validate your `gitlab` or `gitlab-ssl` NGINX config file with the following command:
 ```sh
 sudo nginx -t
 ```
-You should receive `syntax is okay` and `test is successful` messages. If you receive errors check your `gitlab` or `gitlab-ssl` Nginx config file for typos, etc. as indicated in the error message given.
+You should receive `syntax is okay` and `test is successful` messages. If you receive errors check your `gitlab` or `gitlab-ssl` NGINX config file for typos, etc. as indicated in the error message given.
 NOTE: **Note:**
 Verify that the installed version is greater than 1.12.1 by running `nginx -v`. If it's lower, you may receive the error below:
@@ -858,7 +858,7 @@ To use GitLab with HTTPS:
 1. In the `config.yml` of GitLab Shell:
    1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
    1. Set the certificates using either the `ca_file` or `ca_path` option.
-1. Use the `gitlab-ssl` Nginx example config instead of the `gitlab` config.
+1. Use the `gitlab-ssl` NGINX example config instead of the `gitlab` config.
    1. Update `YOUR_SERVER_FQDN`.
    1. Update `ssl_certificate` and `ssl_certificate_key`.
    1. Review the configuration file and consider applying other security and performance enhancing features.
@@ -884,9 +884,9 @@ See the ["Reply by email" documentation](../administration/reply_by_email.md) fo
 You can configure LDAP authentication in `config/gitlab.yml`. Restart GitLab after editing this file.
-### Using Custom Omniauth Providers
-See the [omniauth integration document](../integration/omniauth.md).
+### Using Custom OmniAuth Providers
+See the [OmniAuth integration documentation](../integration/omniauth.md).
 ### Build your projects
@@ -945,7 +945,7 @@ You also need to change the corresponding options (e.g. `ssh_user`, `ssh_host`,
 ### Additional Markup Styles
-Apart from the always supported markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [github-markup gem README](https://github.com/gitlabhq/markup#markups) for more information.
+Apart from the always supported Markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [`github-markup` gem README](https://github.com/gitlabhq/markup#markups) for more information.
 ### Using Puma
@@ -971,12 +971,12 @@ To use GitLab with Puma:
 ### "You appear to have cloned an empty repository."
 If you see this message when attempting to clone a repository hosted by GitLab,
-this is likely due to an outdated Nginx or Apache configuration, or a missing or
+this is likely due to an outdated NGINX or Apache configuration, or a missing or
 misconfigured GitLab Workhorse instance. Double-check that you've
 [installed Go](#3-go), [installed GitLab Workhorse](#install-gitlab-workhorse),
-and correctly [configured Nginx](#site-configuration).
-### google-protobuf "LoadError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found"
+and correctly [configured NGINX](#site-configuration).
+### `google-protobuf` "LoadError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found"
 This can happen on some platforms for some versions of the
 `google-protobuf` gem. The workaround is to install a source-only

doc/install/openshift_and_gitlab/index.md

@@ -14,7 +14,7 @@ for details.
 ## Introduction
 [OpenShift Origin](https://www.okd.io/) (**Note:** renamed to OKD in Aug 2018) is an open source container application
-platform created by [RedHat], based on [kubernetes](https://kubernetes.io/) and [Docker]. That means
+platform created by [RedHat], based on [Kubernetes](https://kubernetes.io/) and [Docker]. That means
 you can host your own PaaS for free and almost with no hassle.
 In this tutorial, we will see how to deploy GitLab in OpenShift using GitLab's
@@ -30,7 +30,7 @@ For a video demonstration on installing GitLab on OpenShift, check the article [
 CAUTION: **Caution:** This information is no longer up to date, as the current versions
 have changed and products have been renamed.
-OpenShift 3 is not yet deployed on RedHat's offered Online platform, [openshift.com](https://www.openshift.com/),
+OpenShift 3 is not yet deployed on RedHat's offered [Online platform](https://www.openshift.com/),
 so in order to test it, we will use an [all-in-one Virtualbox image](https://www.okd.io/minishift/) that is
 offered by the OpenShift developers and managed by Vagrant. If you haven't done
 already, go ahead and install the following components as they are essential to
@@ -44,8 +44,8 @@ It is also important to mention that for the purposes of this tutorial, the
 latest Origin release is used:
 - **oc** `v1.3.0` (must be [installed][oc-gh] locally on your computer)
-- **openshift** `v1.3.0` (is pre-installed in the [VM image][vm-new])
-- **kubernetes** `v1.3.0` (is pre-installed in the [VM image][vm-new])
+- **OpenShift** `v1.3.0` (is pre-installed in the [VM image][vm-new])
+- **Kubernetes** `v1.3.0` (is pre-installed in the [VM image][vm-new])
 >**Note:**
 If you intend to deploy GitLab on a production OpenShift cluster, there are some
@@ -59,7 +59,7 @@ on your computer.
 ## Getting familiar with OpenShift Origin
 The environment we are about to use is based on CentOS 7 which comes with all
-the tools needed pre-installed: Docker, kubernetes, OpenShift, etcd.
+the tools needed pre-installed: Docker, Kubernetes, OpenShift, etcd.
 ### Test OpenShift using Vagrant
@@ -130,7 +130,7 @@ kubernetes v1.3.0+52492b4
 ```
 With `oc help` you can see the top level arguments you can run with `oc` and
-interact with your cluster, kubernetes, run applications, create projects and
+interact with your cluster, Kubernetes, run applications, create projects and
 much more.
 Let's login to the all-in-one VM and see how to achieve the same results like
@@ -349,7 +349,7 @@ tab.
 ![GitLab logs](img/gitlab-logs.png)
-At a point you should see a _**gitlab Reconfigured!**_ message in the logs.
+At a point you should see a `gitlab Reconfigured!` message in the logs.
 Navigate back to the **Overview** and hopefully all pods will be up and running.
 ![GitLab running](img/gitlab-running.png)

doc/install/requirements.md

@@ -148,13 +148,13 @@ CREATE EXTENSION postgres_fdw;
 ## Unicorn Workers
-For most instances we recommend using: (CPU cores * 1.5) + 1 = unicorn workers.
-For example a node with 4 cores would have 7 unicorn workers.
-For all machines that have 2GB and up we recommend a minimum of three unicorn workers.
+For most instances we recommend using: (CPU cores * 1.5) + 1 = Unicorn workers.
+For example a node with 4 cores would have 7 Unicorn workers.
+For all machines that have 2GB and up we recommend a minimum of three Unicorn workers.
 If you have a 1GB machine we recommend to configure only two Unicorn workers to prevent excessive swapping.
-As long as you have enough available CPU and memory capacity, it's okay to increase the number of unicorn workers and this will usually help to reduce the response time of the applications and increase the ability to handle parallel requests.
+As long as you have enough available CPU and memory capacity, it's okay to increase the number of Unicorn workers and this will usually help to reduce the response time of the applications and increase the ability to handle parallel requests.
 To change the Unicorn workers when you have the Omnibus package (which defaults to the recommendation above) please see [the Unicorn settings in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/unicorn.html).

doc/migrate_ci_to_ce/README.md

@@ -268,11 +268,11 @@ If you installed GitLab CI from source we now need to configure a redirect in
 NGINX so that existing CI runners can keep using the old CI server address, and
 so that existing links to your CI server keep working.
-### 1. Update Nginx configuration
+### 1. Update NGINX configuration
 To ensure that your existing CI runners are able to communicate with the
 migrated installation, and that existing build triggers still work, you'll need
-to update your Nginx configuration to redirect requests for the old locations to
+to update your NGINX configuration to redirect requests for the old locations to
 the new ones.
 Edit `/etc/nginx/sites-available/gitlab_ci` and paste:
@@ -324,13 +324,13 @@ You should also make sure that you can:
 1. `curl https://YOUR_GITLAB_SERVER_FQDN/` from your previous GitLab CI server.
 1. `curl https://YOUR_CI_SERVER_FQDN/` from your GitLab CE (or EE) server.
-### 2. Check Nginx configuration
+### 2. Check NGINX configuration
 ```sh
 sudo nginx -t
 ```
-### 3. Restart Nginx
+### 3. Restart NGINX
 ```sh
 sudo /etc/init.d/nginx restart

doc/raketasks/backup_restore.md

@@ -98,7 +98,7 @@ docker exec -t <container name> gitlab-backup create
 NOTE: **Note**
 For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
-If you are using the [GitLab helm chart](https://gitlab.com/gitlab-org/charts/gitlab) on a
+If you are using the [GitLab Helm chart](https://gitlab.com/gitlab-org/charts/gitlab) on a
 Kubernetes cluster, you can run the backup task using `backup-utility` script on
 the GitLab task runner pod via `kubectl`. Refer to [backing up a GitLab installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) for more details:
@@ -775,9 +775,9 @@ If there is a GitLab version mismatch between your backup tar file and the insta
 version of GitLab, the restore command will abort with an error. Install the
 [correct GitLab version](https://packages.gitlab.com/gitlab/) and try again.
-### Restore for Docker image and GitLab helm chart installations
-For GitLab installations using the Docker image or the GitLab helm chart on
+### Restore for Docker image and GitLab Helm chart installations
+For GitLab installations using the Docker image or the GitLab Helm chart on
 a Kubernetes cluster, the restore task expects the restore directories to be empty.
 However, with docker and Kubernetes volume mounts, some system level directories
 may be created at the volume roots, like `lost+found` directory found in Linux
@@ -803,8 +803,8 @@ CAUTION: **Warning:**
 This is a [known issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/62759). On GitLab 12.2 or newer, you can
 use `gitlab-backup restore` to avoid this issue.
-The GitLab helm chart uses a different process, documented in
-[restoring a GitLab helm chart installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md).
+The GitLab Helm chart uses a different process, documented in
+[restoring a GitLab Helm chart installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md).
 ## Alternative backup strategies
@@ -859,7 +859,7 @@ Be advised that, backup is successfully restored in spite of these warnings.
 The rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
 Those objects have no influence on the database backup/restore but they give this annoying warning.
-For more information see similar questions on postgresql issue tracker[here](http://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](http://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](http://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).
+For more information see similar questions on PostgreSQL issue tracker[here](http://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](http://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](http://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).
 ### When the secrets file is lost

doc/security/crime_vulnerability.md

@@ -56,7 +56,7 @@ vulnerability.
 ## References
-- Nginx ["Module ngx_http_spdy_module"][ngx-spdy]
+- NGINX ["Module ngx_http_spdy_module"][ngx-spdy]
 - Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus]
 - Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia

doc/topics/autodevops/index.md

@@ -122,7 +122,7 @@ To make full use of Auto DevOps, you will need:
   - Kubernetes 1.5+.
   - A [Kubernetes cluster][kubernetes-clusters] for the project.
-  - A load balancer. You can use NGINX ingress by deploying it to your
+  - A load balancer. You can use NGINX Ingress by deploying it to your
     Kubernetes cluster by either:
     - Using the [`nginx-ingress`](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress) Helm chart.
     - Installing the Ingress [GitLab Managed App](../../user/clusters/applications.md#ingress).
@@ -331,7 +331,7 @@ If a project's repository contains a `Dockerfile`, Auto Build will use
 If you are also using Auto Review Apps and Auto Deploy and choose to provide
 your own `Dockerfile`, make sure you expose your application to port
 `5000` as this is the port assumed by the
-[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy helm chart](#custom-helm-chart)
+[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy Helm chart](#custom-helm-chart)
 #### Auto Build using Heroku buildpacks
@@ -529,7 +529,7 @@ Auto Deploy doesn't include deployments to staging or canary by default, but the
 enable them.
 You can make use of [environment variables](#environment-variables) to automatically
-scale your pod replicas and to apply custom arguments to the Auto DevOps `helm upgrade` commands. This is an easy way to [customize the Auto Deploy helm chart](#custom-helm-chart).
+scale your pod replicas and to apply custom arguments to the Auto DevOps `helm upgrade` commands. This is an easy way to [customize the Auto Deploy Helm chart](#custom-helm-chart).
 Apps are deployed using the
 [auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with
@@ -572,7 +572,7 @@ within the application pod by setting the project variables `DB_INITIALIZE` and
 `DB_MIGRATE` respectively.
 If present, `DB_INITIALIZE` will be run as a shell command within an
-application pod as a helm post-install hook. As some applications will
+application pod as a Helm post-install hook. As some applications will
 not run without a successful database initialization step, GitLab will
 deploy the first release without the application deployment and only the
 database initialization step. After the database initialization completes,
@@ -583,7 +583,7 @@ Note that a post-install hook means that if any deploy succeeds,
 `DB_INITIALIZE` will not be processed thereafter.
 If present, `DB_MIGRATE` will be run as a shell command within an application pod as
-a helm pre-upgrade hook.
+a Helm pre-upgrade hook.
 For example, in a Rails application in an image built with
 [Herokuish](https://github.com/gliderlabs/herokuish):
@@ -860,27 +860,27 @@ applications.
 | **Variable**                            | **Description**                    |
 |-----------------------------------------|------------------------------------|
-| `ADDITIONAL_HOSTS`                      | Fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. |
-| `<ENVIRONMENT>_ADDITIONAL_HOSTS`        | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
+| `ADDITIONAL_HOSTS`                      | Fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. |
+| `<ENVIRONMENT>_ADDITIONAL_HOSTS`        | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
 | `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`    | Extra arguments to be passed to the `docker build` command. Note that using quotes will not prevent word splitting. [More details](#passing-arguments-to-docker-build). |
 | `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#passing-secrets-to-docker-build) to be passed to the `docker build` command as secrets. |
 | `AUTO_DEVOPS_CHART`                     | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/charts/auto-deploy-app). |
 | `AUTO_DEVOPS_CHART_REPOSITORY`          | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. |
-| `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From Gitlab 11.11, used to set the name of the helm repository. Defaults to `gitlab`. |
-| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From Gitlab 11.11, used to set a username to connect to the helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. |
-| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From Gitlab 11.11, used to set a password to connect to the helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From GitLab 11.11, used to set a username to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
 | `BUILDPACK_URL`                         | Buildpack's full URL. Can point to either Git repositories or a tarball URL. For Git repositories, it is possible to point to a specific `ref`. For example `https://github.com/heroku/heroku-buildpack-ruby.git#v142`. |
 | `CANARY_ENABLED`                        | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments-premium). |
 | `CANARY_PRODUCTION_REPLICAS`            | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. |
 | `CANARY_REPLICAS`                       | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md). Defaults to 1. |
 | `HELM_RELEASE_NAME`                     | From GitLab 12.1, allows the `helm` release name to be overridden. Can be used to assign unique release names when deploying multiple projects to a single namespace. |
-| `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. **Tip:** you can use this variable to [customize the Auto Deploy helm chart](#custom-helm-chart) by applying custom override values with `--values my-values.yaml`. |
+| `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. **Tip:** you can use this variable to [customize the Auto Deploy Helm chart](#custom-helm-chart) by applying custom override values with `--values my-values.yaml`. |
 | `INCREMENTAL_ROLLOUT_MODE`              | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production-premium) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
 | `K8S_SECRET_*`                          | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) will be made available by Auto DevOps as environment variables to the deployed application. |
 | `KUBE_INGRESS_BASE_DOMAIN`              | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/index.md#base-domain) for more information. |
 | `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. |
 | `REPLICAS`                              | Number of replicas to deploy. Defaults to 1. |
-| `ROLLOUT_RESOURCE_TYPE`                 | From GitLab 11.9, allows specification of the resource type being deployed when using a custom helm chart. Default value is `deployment`. |
+| `ROLLOUT_RESOURCE_TYPE`                 | From GitLab 11.9, allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. |
 | `ROLLOUT_STATUS_DISABLED`               | From GitLab 12.0, used to disable rollout status check because it doesn't support all resource types, for example, `cronjob`. |
 | `STAGING_ENABLED`                       | From GitLab 10.8, used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). |

doc/update/mysql_to_postgresql.md

@@ -196,7 +196,7 @@ After the database is created, go on with the following steps:
    sudo -u git -H chmod o-rwx config/database.yml
    ```
-1. Install Gems related to Postgresql
+1. Install Gems related to PostgreSQL
    ```bash
    sudo -u git -H rm .bundle/config

doc/update/patch_versions.md

@@ -72,7 +72,7 @@ cd /home/git/gitlab
 sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
 ```
-### 5. Update gitaly to the corresponding version
+### 5. Update Gitaly to the corresponding version
 ```bash
 cd /home/git/gitlab
@@ -102,7 +102,7 @@ sudo -u git -H make
 ### 8. Install/Update `gitlab-elasticsearch-indexer` (optional) **(STARTER ONLY)**
-If you're interested in using GitLab's new [elasticsearch repository indexer](../integration/elasticsearch.md#elasticsearch-repository-indexer-beta) (currently in beta)
+If you're interested in using GitLab's new [Elasticsearch repository indexer](../integration/elasticsearch.md#elasticsearch-repository-indexer-beta) (currently in beta)
 please follow the instructions on the document linked above and enable the
 indexer usage in the GitLab admin settings.

doc/update/upgrading_from_ce_to_ee.md

@@ -74,8 +74,8 @@ sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS
 ### 4. Install `gitlab-elasticsearch-indexer` (optional) **(STARTER ONLY)**
-If you're interested in using GitLab's new [elasticsearch repository
-indexer](../integration/elasticsearch.md) (currently in beta) please follow the instructions on the
+If you're interested in using GitLab's new [Elasticsearch repository indexer](../integration/elasticsearch.md)
+(currently in beta) please follow the instructions on the
 document linked above and enable the indexer usage in the GitLab admin settings.
 ### 5. Start application

doc/update/upgrading_from_source.md

@@ -253,7 +253,7 @@ cd /home/git/gitlab
 git diff origin/PREVIOUS_BRANCH:config/gitlab.yml.example origin/BRANCH:config/gitlab.yml.example
 ```
-#### Nginx configuration
+#### NGINX configuration
 Ensure you're still up-to-date with the latest NGINX configuration changes:
@@ -268,7 +268,7 @@ git diff origin/PREVIOUS_BRANCH:lib/support/nginx/gitlab origin/BRANCH:lib/suppo
 ```
 If you are using Strict-Transport-Security in your installation to continue
-using it you must enable it in your Nginx configuration as GitLab application no
+using it you must enable it in your NGINX configuration as GitLab application no
 longer handles setting it.
 If you are using Apache instead of NGINX please see the updated [Apache templates].