Add latest changes from gitlab-org/gitlab@master

app/services/clusters/management/create_project_service.rb

+# frozen_string_literal: true
+
+module Clusters
+  module Management
+    class CreateProjectService
+      CreateError = Class.new(StandardError)
+
+      attr_reader :cluster, :current_user
+
+      def initialize(cluster, current_user:)
+        @cluster = cluster
+        @current_user = current_user
+      end
+
+      def execute
+        return unless management_project_required?
+
+        ActiveRecord::Base.transaction do
+          project = create_management_project!
+
+          update_cluster!(project)
+        end
+      end
+
+      private
+
+      def management_project_required?
+        Feature.enabled?(:auto_create_cluster_management_project) && cluster.management_project.nil?
+      end
+
+      def project_params
+        {
+          name: project_name,
+          description: project_description,
+          namespace_id: namespace.id,
+          visibility_level: Gitlab::VisibilityLevel::PRIVATE
+        }
+      end
+
+      def project_name
+        "#{cluster.name} Cluster Management"
+      end
+
+      def project_description
+        "This project is automatically generated and will be used to manage your Kubernetes cluster. [More information](#{docs_path})"
+      end
+
+      def docs_path
+        Rails.application.routes.url_helpers.help_page_path('user/clusters/management_project')
+      end
+
+      def create_management_project!
+        ::Projects::CreateService.new(current_user, project_params).execute.tap do |project|
+          errors = project.errors.full_messages
+
+          if errors.any?
+            raise CreateError.new("Failed to create project: #{errors}")
+          end
+        end
+      end
+
+      def update_cluster!(project)
+        unless cluster.update(management_project: project)
+          raise CreateError.new("Failed to update cluster: #{cluster.errors.full_messages}")
+        end
+      end
+
+      def namespace
+        case cluster.cluster_type
+        when 'project_type'
+          cluster.project.namespace
+        when 'group_type'
+          cluster.group
+        when 'instance_type'
+          instance_administrators_group
+        else
+          raise NotImplementedError
+        end
+      end
+
+      def instance_administrators_group
+        Gitlab::CurrentSettings.instance_administrators_group ||
+          raise(CreateError.new('Instance administrators group not found'))
+      end
+    end
+  end
+end

changelogs/unreleased/208923-enable-batch-counting-for-some-individual-queries-1.yml

+---
+title: Optimize projects_enforcing_code_owner_approval counter query performance for usage ping
+merge_request: 27526
+author:
+type: performance

changelogs/unreleased/add_helm_params_rollback_related.yml

+---
+title: Add atomic and cleanup-on-fail parameters for Helm
+merge_request: 27721
+author:
+type: changed

db/migrate/20200318175008_add_index_on_id_and_archived_and_pending_delete_to_projects.rb

+# frozen_string_literal: true
+
+class AddIndexOnIdAndArchivedAndPendingDeleteToProjects < ActiveRecord::Migration[6.0]
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+  INDEX_NAME = 'index_projects_on_id_and_archived_and_pending_delete'
+
+  disable_ddl_transaction!
+
+  def up
+    add_concurrent_index :projects, :id, where: "archived = FALSE AND pending_delete = FALSE", name: INDEX_NAME
+  end
+
+  def down
+    remove_concurrent_index_by_name :projects, INDEX_NAME
+  end
+end

db/structure.sql

@@ -9627,6 +9627,8 @@ CREATE INDEX index_projects_on_creator_id_and_created_at ON public.projects USIN
 
 CREATE INDEX index_projects_on_description_trigram ON public.projects USING gin (description public.gin_trgm_ops);
 
+CREATE INDEX index_projects_on_id_and_archived_and_pending_delete ON public.projects USING btree (id) WHERE ((archived = false) AND (pending_delete = false));
+
 CREATE UNIQUE INDEX index_projects_on_id_partial_for_visibility ON public.projects USING btree (id) WHERE (visibility_level = ANY (ARRAY[10, 20]));
 
 CREATE INDEX index_projects_on_id_service_desk_enabled ON public.projects USING btree (id) WHERE (service_desk_enabled = true);
@@ -12710,6 +12712,7 @@ INSERT INTO "schema_migrations" (version) VALUES
 ('20200318163148'),
 ('20200318164448'),
 ('20200318165448'),
+('20200318175008'),
 ('20200319203901'),
 ('20200323075043');
 

doc/.vale/gitlab/Substitutions.yml

@@ -3,7 +3,7 @@
 #
 # For a list of all options, see https://errata-ai.github.io/vale/styles/
 extends: substitution
-message: Use "%s" instead of "%s".
+message: 'Use "%s" instead of "%s".'
 link: https://about.gitlab.com/handbook/communication/#top-misused-terms
 level: error
 ignorecase: true
@@ -11,3 +11,4 @@ swap:
   GitLabber: GitLab team member
   self hosted: self-managed
   self-hosted: self-managed
+  postgres: PostgreSQL

doc/.vale/gitlab/VersionText.yml

+---
+# Checks that version text is formatted correctly.
+#
+# Specifically looks for either of the following that is immediately followed on the next line
+# by content, which will break rendering:
+#
+# - `> Introduced` (version text without a link)
+# - `> [Introduced` (version text with a link)
+#
+# Because it excludes `-`, it doesn't look for multi-line version text, for which content
+# immediately on the next line is ok. However, this will often highlight where multi-line version
+# text is attempted without `-` characters.
+#
+# For a list of all options, see https://errata-ai.github.io/vale/styles/
+extends: existence
+message: '"%s" is not formatted correctly.'
+link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#text-for-documentation-requiring-version-text
+level: error
+scope: raw
+raw:
+  - '> (- ){0}\[?Introduced.+\n.+'

doc/administration/audit_events.md

@@ -134,7 +134,7 @@ on adding these events into GitLab:
 
 The current architecture of audit events is not prepared to receive a very high amount of records.
 It may make the user interface for your project or audit logs very busy, and the disk space consumed by the
-`audit_events` Postgres table will increase considerably. It's disabled by default
+`audit_events` PostgreSQL table will increase considerably. It's disabled by default
 to prevent performance degradations on GitLab instances with very high Git write traffic.
 
 In an upcoming release, Audit Logs for Git push events will be enabled

doc/administration/auth/smartcard.md

@@ -25,10 +25,11 @@ GitLab supports two authentication methods:
 
 ### Authentication against a local database with X.509 certificates
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/726) in
-[GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental
-feature. Smartcard authentication against local databases may change or be
-removed completely in future releases.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/726) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental feature.
+
+CAUTION: **Caution:**
+Smartcard authentication against local databases may change or be removed completely in future
+releases.
 
 Smartcards with X.509 certificates can be used to authenticate with GitLab.
 

doc/administration/file_hooks.md

 # File hooks
 
-> Introduced in GitLab 10.6.
-> Until 12.8 the feature name was Plugins.
+> - Introduced in GitLab 10.6.
+> - Until GitLab 12.8, the feature name was Plugins.
 
 With custom file hooks, GitLab administrators can introduce custom integrations
 without modifying GitLab's source code.

doc/administration/geo/replication/datatypes.md

@@ -21,9 +21,9 @@ verification methods:
 | Database | Application data in PostgreSQL                | Native                                      | Native               |
 | Database | Redis                                         | _N/A_ (*1*)                                 | _N/A_                |
 | Database | Elasticsearch                                 | Native                                      | Native               |
-| Database | Personal snippets                             | Postgres Replication                        | Postgres Replication |
-| Database | Project snippets                              | Postgres Replication                        | Postgres Replication |
-| Database | SSH public keys                               | Postgres Replication                        | Postgres Replication |
+| Database | Personal snippets                             | PostgreSQL Replication                        | PostgreSQL Replication |
+| Database | Project snippets                              | PostgreSQL Replication                        | PostgreSQL Replication |
+| Database | SSH public keys                               | PostgreSQL Replication                        | PostgreSQL Replication |
 | Git      | Project repository                            | Geo with Gitaly                             | Gitaly Checksum      |
 | Git      | Project wiki repository                       | Geo with Gitaly                             | Gitaly Checksum      |
 | Git      | Project designs repository                    | Geo with Gitaly                             | Gitaly Checksum      |

doc/administration/geo/replication/troubleshooting.md

@@ -242,7 +242,7 @@ sudo gitlab-rake gitlab:geo:check
    Checking Geo ... Finished
    ```
 
-   When performing a Postgres major version (9 > 10) update this is expected. Follow:
+   When performing a PostgreSQL major version (9 > 10) update this is expected. Follow:
 
    - [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
    - [Geo database has an outdated FDW remote schema](troubleshooting.md#geo-database-has-an-outdated-fdw-remote-schema-error)

doc/administration/high_availability/database.md

@@ -146,7 +146,7 @@ Each service in the package comes with a set of [default ports](https://docs.git
 - Application servers connect to either PgBouncer directly via its [default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#pgbouncer) or via a configured Internal Load Balancer (TCP) that serves multiple PgBouncers.
 - PgBouncer connects to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
 - Repmgr connects to the database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
-- Postgres secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
+- PostgreSQL secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
 - Consul servers and agents connect to each others [Consul default ports](https://docs.gitlab.com/omnibus/package-information/defaults.html#consul)
 
 #### Required information
@@ -899,7 +899,7 @@ after it has been restored to service.
   ```shell
   gitlab-ctl repmgr standby unregister --node=959789412
   ```
-  
+
 ##### Add a node as a standby server
 
   From the stnadby node, run:
@@ -916,24 +916,24 @@ after it has been restored to service.
   scratch by performing a `gitlab-ctl repmgr standby setup NEW_MASTER`.
 
 ##### Add a failed master back into the cluster as a standby node
-  
+
   Once `repmgrd` and PostgreSQL are runnning, the node will need to follow the new
   as a standby node.
-  
+
   ```
   gitlab-ctl repmgr standby follow NEW_MASTER
   ```
-  
+
   Once the node is following the new master as a standby, the node needs to be
   [unregistered from the cluster on the new master node](#remove-a-standby-from-the-cluster).
-  
+
   Once the old master node has been unregistered from the cluster, it will need
   to be setup as a new standby:
-  
+
   ```
   gitlab-ctl repmgr standby setup NEW_MASTER
   ```
-  
+
   Failure to unregister and readd the old master node can lead to subsequent failovers
   not working.
 

doc/administration/high_availability/nfs.md

@@ -132,7 +132,7 @@ across NFS. The GitLab support team will not be able to assist on performance is
 this configuration.
 
 Additionally, this configuration is specifically warned against in the
-[Postgres Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
+[PostgreSQL Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
 
 >PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like
 >locally-connected drives. If the client or server NFS implementation does not provide standard file

doc/administration/high_availability/sidekiq.md

@@ -55,7 +55,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_rails['gitaly_token'] = 'YOUR_TOKEN'
    ```
 
-1. Setup Sidekiq's connection to Postgres:
+1. Setup Sidekiq's connection to PostgreSQL:
 
    ```ruby
    gitlab_rails['db_host'] = '10.10.1.30'
@@ -66,7 +66,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_rails['auto_migrate'] = false
    ```
 
-   Remember to add the Sidekiq nodes to the Postgres whitelist:
+   Remember to add the Sidekiq nodes to the PostgreSQL whitelist:
 
    ```ruby
    postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 10.10.1.30/32 10.10.1.31/32 10.10.1.32/32 10.10.1.33/32 10.10.1.38/32)

doc/administration/integration/terminal.md

 # Web terminals
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690)
-in GitLab 8.15. Only project maintainers and owners can access web terminals.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690) in GitLab 8.15.
+
+NOTE: **Note:**
+Only project maintainers and owners can access web terminals.
 
 With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
 GitLab gained the ability to store and use credentials for a Kubernetes cluster.
@@ -92,8 +94,7 @@ they will receive a `Connection failed` message.
 
 ## Limiting WebSocket connection time
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413)
-in GitLab 8.17.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413) in GitLab 8.17.
 
 Terminal sessions use long-lived connections; by default, these may last
 forever. You can configure a maximum session time in the Admin Area of your

doc/administration/logs.md

@@ -13,7 +13,7 @@ This guide talks about how to read and use these system log files.
 This file lives in `/var/log/gitlab/gitlab-rails/production_json.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/production_json.log` for
 installations from source. When GitLab is running in an environment
-other than production, the corresponding logfile is shown here.
+other than production, the corresponding log file is shown here.
 
 It contains a structured log for Rails controller requests received from
 GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/). Note that
@@ -105,7 +105,7 @@ NOTE: **Note:** Starting with GitLab 12.5, if an error occurs, an
 This file lives in `/var/log/gitlab/gitlab-rails/production.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/production.log` for
 installations from source. (When GitLab is running in an environment
-other than production, the corresponding logfile is shown here.)
+other than production, the corresponding log file is shown here.)
 
 It contains information about all performed requests. You can see the
 URL and type of request, IP address, and what parts of code were

doc/administration/monitoring/performance/grafana_configuration.md

@@ -39,8 +39,8 @@ Test Connection to ensure the configuration is correct.
 - **Name**: `InfluxDB`
 - **Default**: Checked
 - **Type**: `InfluxDB 0.9.x` (Even if you're using InfluxDB 0.10.x)
-- **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB
-  on a separate server)
+- For the URL, use `https://localhost:8086`, or provide the remote URL if you've installed InfluxDB
+  on a separate server
 - **Access**: `proxy`
 - **Database**: `gitlab`
 - **User**: `admin` (Or the username configured when setting up InfluxDB)
@@ -52,7 +52,7 @@ Test Connection to ensure the configuration is correct.
 
 If you intend to import the GitLab provided Grafana dashboards, you will need to
 set up the right retention policies and continuous queries. The easiest way of
-doing this is by using the [influxdb-management](https://gitlab.com/gitlab-org/influxdb-management)
+doing this is by using the [InfluxDB Management](https://gitlab.com/gitlab-org/influxdb-management)
 repository.
 
 To use this repository you must first clone it:
@@ -74,7 +74,7 @@ and then editing the `.env` file to contain the correct InfluxDB settings. Once
 configured you can simply run `bundle exec rake` and the InfluxDB database will
 be configured for you.
 
-For more information see the [influxdb-management README](https://gitlab.com/gitlab-org/influxdb-management/blob/master/README.md).
+For more information see the [InfluxDB Management README](https://gitlab.com/gitlab-org/influxdb-management/blob/master/README.md).
 
 ## Import Dashboards
 

doc/administration/monitoring/performance/performance_bar.md

@@ -33,7 +33,7 @@ page was open. Only the first two requests per unique URL are captured.
 
 ## Request warnings
 
-For requests exceeding pre-defined limits, a warning icon will be shown
+For requests exceeding predefined limits, a warning icon will be shown
 next to the failing metric, along with an explanation. In this example,
 the Gitaly call duration exceeded the threshold:
 

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -201,7 +201,7 @@ When Puma is used instead of Unicorn, the following metrics are available:
 | `puma_running_workers`                         | Gauge   | 12.0  | Number of booted workers |
 | `puma_stale_workers`                           | Gauge   | 12.0  | Number of old workers |
 | `puma_running`                                 | Gauge   | 12.0  | Number of running threads |
-| `puma_queued_connections`                      | Gauge   | 12.0  | Number of connections in that worker's "todo" set waiting for a worker thread |
+| `puma_queued_connections`                      | Gauge   | 12.0  | Number of connections in that worker's "to do" set waiting for a worker thread |
 | `puma_active_connections`                      | Gauge   | 12.0  | Number of threads processing a request |
 | `puma_pool_capacity`                           | Gauge   | 12.0  | Number of requests the worker is capable of taking right now |
 | `puma_max_threads`                             | Gauge   | 12.0  | Maximum number of worker threads |

doc/administration/monitoring/prometheus/index.md

@@ -268,42 +268,42 @@ export Prometheus metrics.
 The node exporter allows you to measure various machine resources, such as
 memory, disk, and CPU utilization.
 
-[➔ Read more about the node exporter.](node_exporter.md)
+[Read more about the node exporter](node_exporter.md).
 
 ### Redis exporter
 
 The Redis exporter allows you to measure various Redis metrics.
 
-[➔ Read more about the Redis exporter.](redis_exporter.md)
+[Read more about the Redis exporter](redis_exporter.md).
 
-### Postgres exporter
+### PostgreSQL exporter
 
-The Postgres exporter allows you to measure various PostgreSQL metrics.
+The PostgreSQL exporter allows you to measure various PostgreSQL metrics.
 
-[➔ Read more about the Postgres exporter.](postgres_exporter.md)
+[Read more about the PostgreSQL exporter](postgres_exporter.md).
 
 ### PgBouncer exporter
 
 The PgBouncer exporter allows you to measure various PgBouncer metrics.
 
-[➔ Read more about the PgBouncer exporter.](pgbouncer_exporter.md)
+[Read more about the PgBouncer exporter](pgbouncer_exporter.md).
 
 ### Registry exporter
 
 The Registry exporter allows you to measure various Registry metrics.
 
-[➔ Read more about the Registry exporter.](registry_exporter.md)
+[Read more about the Registry exporter](registry_exporter.md).
 
 ### GitLab exporter
 
 The GitLab exporter allows you to measure various GitLab metrics, pulled from Redis and the database.
 
-[➔ Read more about the GitLab exporter.](gitlab_exporter.md)
+[Read more about the GitLab exporter](gitlab_exporter.md).
 
 ## Configuring Prometheus to monitor Kubernetes
 
-> Introduced in GitLab 9.0.
-> Pod monitoring introduced in GitLab 9.4.
+> - Introduced in GitLab 9.0.
+> - Pod monitoring introduced in GitLab 9.4.
 
 If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][prometheus integration] to monitor them.
 

doc/administration/monitoring/prometheus/pgbouncer_exporter.md

@@ -22,8 +22,8 @@ To enable the PgBouncer exporter:
 Prometheus will now automatically begin collecting performance data from
 the PgBouncer exporter exposed under `localhost:9188`.
 
-The PgBouncer exporter will also be enabled by default if the [pgbouncer_role][postgres roles]
-is enabled.
+The PgBouncer exporter will also be enabled by default if the [`pgbouncer_role`][postgres roles]
+role is enabled.
 
 [← Back to the main Prometheus page](index.md)
 

doc/administration/operations/fast_ssh_key_lookup.md

 # Fast lookup of authorized SSH keys in the database
 
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
+> - [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab Community Edition 10.4.
+
 NOTE: **Note:** This document describes a drop-in replacement for the
 `authorized_keys` file for normal (non-deploy key) users. Consider
 using [SSH certificates](ssh_certificates.md), they are even faster,
 but are not a drop-in replacement.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in
-> [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
->
-> [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab
-> Community Edition 10.4.
-
 Regular SSH operations become slow as the number of users grows because OpenSSH
 searches for a key to authorize a user via a linear search. In the worst case,
 such as when the user is not authorized to access GitLab, OpenSSH will scan the
@@ -101,7 +98,7 @@ This is a brief overview. Please refer to the above instructions for more contex
 1. [Rebuild the `authorized_keys` file](../raketasks/maintenance.md#rebuild-authorized_keys-file)
 1. Enable writes to the `authorized_keys` file in Application Settings
 1. Remove the `AuthorizedKeysCommand` lines from `/etc/ssh/sshd_config` or from `/assets/sshd_config` if you are using Omnibus Docker.
-1. Reload sshd: `sudo service sshd reload`
+1. Reload `sshd`: `sudo service sshd reload`
 1. Remove the `/opt/gitlab-shell/authorized_keys` file
 
 ## Compiling a custom version of OpenSSH for CentOS 6
@@ -187,7 +184,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
    You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
 
-   If not, you may need to restart sshd (e.g. `systemctl restart sshd.service`).
+   If not, you may need to restart `sshd` (e.g. `systemctl restart sshd.service`).
 
 1. *IMPORTANT!* Open a new SSH session to your server before exiting to make
    sure everything is working! If you need to downgrade, simple install the

doc/administration/operations/moving_repositories.md

@@ -31,7 +31,7 @@ If you want to see progress, replace `-xf` with `-xvf`.
 ### Tar pipe to another server
 
 You can also use a tar pipe to copy data to another server. If your
-`git` user has SSH access to the newserver as `git@newserver`, you
+`git` user has SSH access to the new server as `git@newserver`, you
 can pipe the data through SSH.
 
 ```shell

doc/administration/operations/ssh_certificates.md

@@ -33,7 +33,7 @@ uploading user SSH keys to GitLab entirely.
 
 How to fully set up SSH certificates is outside the scope of this
 document. See [OpenSSH's
-PROTOCOL.certkeys](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
+`PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
 for how it works, and e.g. [RedHat's documentation about
 it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication).
 

doc/administration/packages/index.md

@@ -57,7 +57,7 @@ local location or even use object storage.
 
 The packages for Omnibus GitLab installations are stored under
 `/var/opt/gitlab/gitlab-rails/shared/packages/` and for source
-installations under `shared/packages/` (relative to the Git homedir).
+installations under `shared/packages/` (relative to the Git home directory).
 To change the local storage path:
 
 **Omnibus GitLab installations**

doc/administration/pages/index.md

@@ -38,7 +38,7 @@ which you can set it up:
    the Pages daemon is installed, so you will have to share it via network.
 - Run the Pages daemon in the same server as GitLab, listening on the same IP
    but on different ports. In that case, you will have to proxy the traffic with
-   a loadbalancer. If you choose that route note that you should use TCP load
+   a load balancer. If you choose that route note that you should use TCP load
    balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
    pages will not be able to be served with user provided certificates. For
    HTTP it's OK to use HTTP or TCP load balancing.
@@ -256,7 +256,7 @@ GitLab supports [custom domain verification](../../user/project/pages/custom_dom
 When adding a custom domain, users will be required to prove they own it by
 adding a GitLab-controlled verification code to the DNS records for that domain.
 
-If your userbase is private or otherwise trusted, you can disable the
+If your user base is private or otherwise trusted, you can disable the
 verification requirement. Navigate to **Admin Area > Settings > Preferences** and
 uncheck **Require users to prove ownership of custom domains** in the **Pages** section.
 This setting is enabled by default.
@@ -358,7 +358,7 @@ For Omnibus, normally this would be fixed by [installing a custom CA in GitLab O
 but a [bug](https://gitlab.com/gitlab-org/gitlab/issues/25411) is currently preventing
 that method from working. Use the following workaround:
 
-1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
+1. Append your GitLab server TLS/SSL certificate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
 
    ```shell
    printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
@@ -582,7 +582,7 @@ but commented out to help encourage others to add to it in the future. -->
 
 ### `open /etc/ssl/ca-bundle.pem: permission denied`
 
-GitLab Pages runs inside a `chroot` jail, usually in a uniquely numbered directory like
+GitLab Pages runs inside a chroot jail, usually in a uniquely numbered directory like
 `/tmp/gitlab-pages-*`.
 
 Within the jail, a bundle of trusted certificates is
@@ -592,7 +592,7 @@ from `/opt/gitlab/embedded/ssl/certs/cacert.pem`
 as part of starting up Pages.
 
 If the permissions on the source file are incorrect (they should be `0644`) then
-the file inside the `chroot` jail will also be wrong.
+the file inside the chroot jail will also be wrong.
 
 Pages will log errors in `/var/log/gitlab/gitlab-pages/current` like:
 
@@ -601,7 +601,7 @@ x509: failed to load system roots and no roots provided
 open /etc/ssl/ca-bundle.pem: permission denied
 ```
 
-The use of a `chroot` jail makes this error misleading, as it is not
+The use of a chroot jail makes this error misleading, as it is not
 referring to `/etc/ssl` on the root filesystem.
 
 The fix is to correct the source file permissions and restart Pages:

doc/administration/pages/source.md

@@ -35,7 +35,7 @@ which you can set it up:
    the Pages daemon is installed, so you will have to share it via network.
 1. Run the Pages daemon in the same server as GitLab, listening on the same IP
    but on different ports. In that case, you will have to proxy the traffic with
-   a loadbalancer. If you choose that route note that you should use TCP load
+   a load balancer. If you choose that route note that you should use TCP load
    balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
    pages will not be able to be served with user provided certificates. For
    HTTP it's OK to use HTTP or TCP load balancing.
@@ -51,7 +51,7 @@ Before proceeding with the Pages configuration, make sure that:
    this document we assume that to be `example.io`.
 1. You have configured a **wildcard DNS record** for that domain.
 1. You have installed the `zip` and `unzip` packages in the same server that
-   GitLab is installed since they are needed to compress/uncompress the
+   GitLab is installed since they are needed to compress and decompress the
    Pages artifacts.
 1. (Optional) You have a **wildcard certificate** for the Pages domain if you
    decide to serve Pages (`*.example.io`) under HTTPS.
@@ -388,7 +388,7 @@ Each request to view a resource in a private site is authenticated by Pages
 using that token. For each request it receives, it makes a request to the GitLab
 API to check that the user is authorized to read that site.
 
-From [GitLab 12.8](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3689) onwards,
+From [GitLab 12.8](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3689) onward,
 Access Control parameters for Pages are set in a configuration file, which
 by convention is named `gitlab-pages-config`. The configuration file is passed to
 pages using the `-config flag` or CONFIG environment variable.

doc/administration/raketasks/check.md

@@ -129,7 +129,7 @@ Done!
 
 ## LDAP Check
 
-The LDAP check Rake task will test the bind_dn and password credentials
+The LDAP check Rake task will test the bind DN and password credentials
 (if configured) and will list a sample of LDAP users. This task is also
 executed as part of the `gitlab:check` task, but can run independently.
 See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.

doc/administration/reply_by_email_postfix_setup.md

@@ -184,13 +184,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
    imapd start
    ```
 
-1. The courier-authdaemon isn't started after installation. Without it, imap authentication will fail:
+1. The `courier-authdaemon` isn't started after installation. Without it, IMAP authentication will fail:
 
    ```shell
    sudo service courier-authdaemon start
    ```
 
-   You can also configure courier-authdaemon to start on boot:
+   You can also configure `courier-authdaemon` to start on boot:
 
    ```shell
    sudo systemctl enable courier-authdaemon

doc/administration/repository_checks.md

 # Repository checks
 
-> [Introduced][ce-3232] in GitLab 8.7. It is OFF by default because it still
-causes too many false alarms.
+> [Introduced][ce-3232] in GitLab 8.7.
 
 Git has a built-in mechanism, [`git fsck`][git-fsck], to verify the
 integrity of all data committed to a repository. GitLab administrators
@@ -11,6 +10,9 @@ before the check result is visible on the project admin page. If the
 checks failed you can see their output on the admin log page under
 'repocheck.log'.
 
+NOTE: **Note:**
+It is OFF by default because it still causes too many false alarms.
+
 ## Periodic checks
 
 When enabled, GitLab periodically runs a repository check on all project

doc/administration/restart_gitlab.md

@@ -37,7 +37,7 @@ sudo gitlab-ctl restart
 
 The output should be similar to this:
 
-```
+```plaintext
 ok: run: gitlab-workhorse: (pid 11291) 1s
 ok: run: logrotate: (pid 11299) 0s
 ok: run: mailroom: (pid 11306) 0s
@@ -103,13 +103,13 @@ depend on those files.
 If you have followed the official installation guide to [install GitLab from
 source][install], run the following command to restart GitLab:
 
-```
+```shell
 sudo service gitlab restart
 ```
 
 The output should be similar to this:
 
-```
+```plaintext
 Shutting down GitLab Unicorn
 Shutting down GitLab Sidekiq
 Shutting down GitLab Workhorse

doc/administration/troubleshooting/debug.md

@@ -118,7 +118,7 @@ downtime. Otherwise skip to the next section.
    ```
 
 1. This forces the process to generate a Ruby backtrace. Check
-   `/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtace. For example, you may see:
+   `/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtrace. For example, you may see:
 
    ```plaintext
    from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'

doc/administration/troubleshooting/diagnostics_tools.md

@@ -19,7 +19,7 @@ running on.
 ## strace-parser
 
 [strace-parser](https://gitlab.com/wchandler/strace-parser) is a small tool to analyze
-and summarize raw strace data.
+and summarize raw `strace` data.
 
 ## Pritaly
 

doc/administration/troubleshooting/elasticsearch.md

@@ -8,7 +8,7 @@ Troubleshooting Elasticsearch requires:
 ## Common terminology
 
 - **Lucene**: A full-text search library written in Java.
-- **Near Realtime (NRT)**: Refers to the slight latency from the time to index a
+- **Near real time (NRT)**: Refers to the slight latency from the time to index a
   document to the time when it becomes searchable.
 - **Cluster**: A collection of one or more nodes that work together to hold all
   the data, providing indexing and search capabilities.
@@ -271,7 +271,7 @@ Generally speaking, ensure:
 - The Elasticsearch server have enough RAM and CPU cores.
 - That sharding **is** being used.
 
-Going into some more detail here, if Elasticsearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, Elasticsearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
+Going into some more detail here, if Elasticsearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, Elasticsearch, which requires ample resources, should be running on its own server (maybe coupled with Logstash and Kibana).
 
 When it comes to Elasticsearch, RAM is the key resource. Elasticsearch themselves recommend:
 

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -162,7 +162,7 @@ and they will assist you with any issues you are having.
   kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo
   ```
 
-- How to connect to a GitLab Postgres database:
+- How to connect to a GitLab PostgreSQL database:
 
   ```shell
   kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole -p

doc/administration/troubleshooting/sidekiq.md

@@ -25,7 +25,7 @@ the `SIDEKIQ_LOG_ARGUMENTS` [environment variable](https://docs.gitlab.com/omnib
 
 Example:
 
-```
+```ruby
 gitlab_rails['env'] = {"SIDEKIQ_LOG_ARGUMENTS" => "1"}
 ```
 
@@ -43,7 +43,7 @@ single argument containing the string `"..."`.
 Send the Sidekiq process ID the `TTIN` signal and it will output thread
 backtraces in the log file.
 
-```
+```shell
 kill -TTIN <sidekiq_pid>
 ```
 
@@ -95,7 +95,7 @@ sudo perf record -p <sidekiq_pid>
 Let this run for 30-60 seconds and then press Ctrl-C. Then view the perf report:
 
 ```shell
-sudo perf report
+$ sudo perf report
 
 # Sample output
 Samples: 348K of event 'cycles', Event count (approx.): 280908431073

doc/api/README.md

@@ -181,8 +181,7 @@ Impersonation tokens are used exactly like regular personal access tokens, and c
 
 #### Disable impersonation
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/40385) in GitLab
-11.6.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/40385) in GitLab 11.6.
 
 By default, impersonation is enabled. To disable impersonation:
 

doc/api/group_badges.md

 # Group badges API
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17082)
-in GitLab 10.6.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17082) in GitLab 10.6.
 
 ## Placeholder tokens
 

doc/api/group_clusters.md

 # Group clusters API
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30213)
-in GitLab 12.1.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30213) in GitLab 12.1.
 
 NOTE: **Note:**
 User will need at least maintainer access for the group to use these endpoints.

doc/api/project_badges.md

 # Project badges API
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17082)
-in GitLab 10.6.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17082) in GitLab 10.6.
 
 ## Placeholder tokens
 

doc/ci/docker/using_docker_images.md

@@ -350,8 +350,7 @@ Alias support for the Kubernetes executor was [introduced](https://gitlab.com/gi
 
 ### Starting multiple services from the same image
 
-> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended
-configuration options](#extended-docker-configuration-options).
+> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended configuration options](#extended-docker-configuration-options).
 
 Before the new extended Docker configuration options, the following configuration
 would not work properly:
@@ -384,8 +383,7 @@ in `.gitlab-ci.yml` file.
 
 ### Setting a command for the service
 
-> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended
-configuration options](#extended-docker-configuration-options).
+> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended configuration options](#extended-docker-configuration-options).
 
 Let's assume you have a `super/sql:latest` image with some SQL database
 inside it and you would like to use it as a service for your job. Let's also
@@ -426,8 +424,7 @@ As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`][cmd].
 
 ### Overriding the entrypoint of an image
 
-> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended
-configuration options](#extended-docker-configuration-options).
+> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended configuration options](#extended-docker-configuration-options).
 
 Before showing the available entrypoint override methods, let's describe shortly
 how the Runner starts and uses a Docker image for the containers used in the

doc/ci/docker/using_kaniko.md

@@ -4,8 +4,7 @@ type: howto
 
 # Building images with kaniko and GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/45512) in GitLab 11.2.
-Requires GitLab Runner 11.2 and above.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/45512) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
 
 [kaniko](https://github.com/GoogleContainerTools/kaniko) is a tool to build
 container images from a Dockerfile, inside a container or Kubernetes cluster.

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

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

doc/ci/junit_test_reports.md

@@ -4,8 +4,7 @@ type: reference
 
 # JUnit test reports
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/45318) in GitLab 11.2.
-Requires GitLab Runner 11.2 and above.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/45318) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
 
 ## Overview
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -5,8 +5,8 @@ last_update: 2019-07-03
 
 # Merge Trains **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9186) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.0.
-> [Squash and merge](../../../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/issues/13001) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.6.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9186) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.0.
+> - [Squash and merge](../../../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/issues/13001) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.6.
 
 [Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) introduces
 running a build on the result of the merged code prior to merging, as a way to keep master green.

doc/ci/metrics_reports.md

@@ -4,8 +4,7 @@ type: reference
 
 # Metrics Reports **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9788) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
-Requires GitLab Runner 11.10 and above.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9788) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. Requires GitLab Runner 11.10 and above.
 
 ## Overview
 

doc/ci/pipelines/index.md

@@ -110,8 +110,7 @@ For example:
 
 ### Expanding and collapsing job log sections
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/14664) in GitLab
-> 12.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/14664) in GitLab 12.0.
 
 Job logs are divided into sections that can be collapsed or expanded. Each section will display
 the duration.

doc/ci/yaml/README.md

@@ -2218,8 +2218,7 @@ job:
 
 #### `artifacts:reports`
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in
-GitLab 11.2. Requires GitLab Runner 11.2 and above.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
 
 The `reports` keyword is used for collecting test reports, code quality reports, and security reports from jobs.
 It also exposes these reports in GitLab's UI (merge requests, pipeline views, and security dashboards).
@@ -2235,8 +2234,7 @@ If you also want the ability to browse the report output files, include the
 
 ##### `artifacts:reports:junit`
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in
-GitLab 11.2. Requires GitLab Runner 11.2 and above.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
 
 The `junit` report collects [JUnit XML files](https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.rsar.analysis.codereview.cobol.doc/topics/cac_useresults_junit.html)
 as artifacts. Although JUnit was originally developed in Java, there are many
@@ -2288,8 +2286,7 @@ There are a couple of limitations on top of the [original dotenv rules](https://
 
 ##### `artifacts:reports:cobertura`
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3708) in GitLab 12.9.
-> Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3708) in GitLab 12.9. Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above.
 
 The `cobertura` report collects [Cobertura coverage XML files](../../user/project/merge_requests/test_coverage_visualization.md).
 The collected Cobertura coverage reports will be uploaded to GitLab as an artifact
@@ -3620,9 +3617,11 @@ Learn more about [variables and their priority][variables].
 
 #### Git strategy
 
-> Introduced in GitLab 8.9 as an experimental feature. May change or be removed
-> completely in future releases. `GIT_STRATEGY=none` requires GitLab Runner
-> v1.7+.
+> - Introduced in GitLab 8.9 as an experimental feature.
+> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
+
+CAUTION: **Caution:**
+May change or be removed completely in future releases.
 
 You can set the `GIT_STRATEGY` used for getting recent application code, either
 globally or per-job in the [`variables`](#variables) section. If left
@@ -3783,8 +3782,10 @@ You can set them globally or per-job in the [`variables`](#variables) section.
 
 #### Shallow cloning
 
-> Introduced in GitLab 8.9 as an experimental feature. May change in future
-releases or be removed completely.
+> Introduced in GitLab 8.9 as an experimental feature.
+
+CAUTION: **Caution:**
+May change in future releases or be removed completely.
 
 You can specify the depth of fetching and cloning using `GIT_DEPTH`. This allows
 shallow cloning of the repository which can significantly speed up cloning for

doc/development/architecture.md

@@ -144,7 +144,7 @@ Component statuses are linked to configuration documentation for each component.
 | [GitLab self-monitoring: Sentry](#sentry) | Track errors generated by the GitLab instance | [⤓][sentry-omnibus] | [❌][sentry-charts] | [❌][sentry-charts] | [✅](https://about.gitlab.com/handbook/support/workflows/500_errors.html#searching-sentry) | [⤓][gitlab-yml] | [⤓][gitlab-yml] | CE & EE |
 | [GitLab self-monitoring: Jaeger](#jaeger) | View traces generated by the GitLab instance | [❌][jaeger-omnibus] | [❌][jaeger-charts] | [❌][jaeger-charts] | [❌](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4104) | [⤓][jaeger-source] | [⚙][jaeger-gdk] | CE & EE |
 | [Redis Exporter](#redis-exporter) | Prometheus endpoint with Redis metrics | [✅][redis-exporter-omnibus] | [✅][redis-exporter-charts] | [✅][redis-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
-| [Postgres Exporter](#postgres-exporter) | Prometheus endpoint with PostgreSQL metrics | [✅][postgres-exporter-omnibus] | [✅][postgres-exporter-charts] | [✅][postgres-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
+| [PostgreSQL Exporter](#postgresql-exporter) | Prometheus endpoint with PostgreSQL metrics | [✅][postgres-exporter-omnibus] | [✅][postgres-exporter-charts] | [✅][postgres-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [PgBouncer Exporter](#pgbouncer-exporter) | Prometheus endpoint with PgBouncer metrics | [⚙][pgbouncer-exporter-omnibus] | [❌][pgbouncer-exporter-charts] | [❌][pgbouncer-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [GitLab Exporter](#gitlab-exporter) | Generates a variety of GitLab metrics | [✅][gitlab-exporter-omnibus] | [✅][gitlab-exporter-charts] | [✅][gitlab-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [N/A][node-exporter-charts] | [N/A][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
@@ -366,14 +366,14 @@ Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics.
 
 GitLab packages the popular Database to provide storage for Application meta data and user information.
 
-#### Postgres Exporter
+#### PostgreSQL Exporter
 
 - [Project page](https://github.com/wrouesnel/postgres_exporter/blob/master/README.md)
 - Configuration: [Omnibus][postgres-exporter-omnibus], [Charts][postgres-exporter-charts]
 - Layer: Monitoring
 - Process: `postgres-exporter`
 
-[Postgres-exporter](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about Postgres to Prometheus for use in Grafana Dashboards.
+[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about PostgreSQL to Prometheus for use in Grafana Dashboards.
 
 #### Prometheus
 
@@ -486,7 +486,7 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
 - NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Unicorn.
 - Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
-- Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
+- PostgreSQL/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 
 ### GitLab Git Request Cycle
 

doc/development/diffs.md

@@ -26,7 +26,7 @@ The diffs fetching process _limits_ single file diff sizes and the overall size
 then persisted on `merge_request_diff_files` table.
 
 Even though diffs larger than 10% of the value of `ApplicationSettings#diff_max_patch_bytes` are collapsed,
-we still keep them on Postgres. However, diff files larger than defined _safety limits_
+we still keep them on PostgreSQL. However, diff files larger than defined _safety limits_
 (see the [Diff limits section](#diff-limits)) are _not_ persisted in the database.
 
 In order to present diffs information on the Merge Request diffs page, we:

doc/development/documentation/styleguide.md

@@ -1132,26 +1132,28 @@ a helpful link back to how the feature was developed.
 
 - For features that need to declare the GitLab version that the feature was introduced. Text similar
   to the following should be added immediately below the heading as a blockquote:
-
-  ```md
-  > Introduced in GitLab 11.3.
-  ```
+  - `> Introduced in GitLab 11.3.`.
 
 - Whenever possible, version text should have a link to the issue, merge request, or epic that introduced the feature.
   An issue is preferred over a merge request, and a merge request is preferred over an epic. For example:
-
-  ```md
-  > [Introduced](<link-to-issue>) in GitLab 11.3.
-  ```
+  - `> [Introduced](<link-to-issue>) in GitLab 11.3.`.
 
 - If the feature is only available in GitLab Enterprise Edition, mention
   the [paid tier](https://about.gitlab.com/handbook/marketing/product-marketing/#tiers)
   the feature is available in:
+  - `> [Introduced](<link-to-issue>) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.`.
+
+- If listing information for multiple version as a feature evolves, add the information to a
+  block-quoted bullet list. For example:
 
   ```md
-  > [Introduced](<link-to-issue>) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.
+  > - [Introduced](<link-to-issue>) in GitLab 11.3.
+  > - Enabled by default in GitLab 11.4.
   ```
 
+NOTE: **Note:**
+Version text must be on its own line and surounded by blank lines to render correctly.
+
 ### Importance of referencing GitLab versions and tiers
 
 Mentioning GitLab versions and tiers is important to all users and contributors

doc/development/filtering_by_label.md

@@ -80,7 +80,7 @@ it did not improve query performance.
 ## Attempt B: Denormalize using an array column
 
 Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/blog/2019/06/27/removing-mysql-support/),
-using [Postgres's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
+using [PostgreSQL's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
 tractable as we didn't have to support two databases. We discussed denormalizing
 the `label_links` table for querying in
 [issue #49651](https://gitlab.com/gitlab-org/gitlab-foss/issues/49651),

doc/development/merge_request_performance_guidelines.md

@@ -205,7 +205,7 @@ Using [`ReactiveCaching`](utilities.md#reactivecaching) is one of the best solut
 
 **Summary:** You should avoid accessing to external services like Gitaly during database
 transactions, otherwise it leads to severe contention problems
-as an open transaction basically blocks the release of a Postgres backend connection.
+as an open transaction basically blocks the release of a PostgreSQL backend connection.
 
 For keeping transaction as minimal as possible, please consider using `AfterCommitQueue`
 module or `after_commit` AR hook.

doc/development/sidekiq_style_guide.md

@@ -181,7 +181,7 @@ execution latency requirements (but also has lower scheduling targets).
 ## Jobs with External Dependencies
 
 Most background jobs in the GitLab application communicate with other GitLab
-services. For example, Postgres, Redis, Gitaly, and Object Storage. These are considered
+services. For example, PostgreSQL, Redis, Gitaly, and Object Storage. These are considered
 to be "internal" dependencies for a job.
 
 However, some jobs will be dependent on external services in order to complete
@@ -224,7 +224,7 @@ Workers that are constrained by CPU or memory resource limitations should be
 annotated with the `worker_resource_boundary` method.
 
 Most workers tend to spend most of their time blocked, wait on network responses
-from other services such as Redis, Postgres and Gitaly. Since Sidekiq is a
+from other services such as Redis, PostgreSQL, and Gitaly. Since Sidekiq is a
 multithreaded environment, these jobs can be scheduled with high concurrency.
 
 Some workers, however, spend large amounts of time _on-CPU_ running logic in

doc/development/understanding_explain_plans.md

@@ -651,8 +651,8 @@ different queries. The only _rule_ is that you _must always measure_ your query
 (preferably using a production-like database) using `EXPLAIN (ANALYZE, BUFFERS)`
 and related tools such as:
 
-- <https://explain.depesz.com/>
-- <http://tatiyants.com/postgres-query-plan-visualization/>
+- [`explain.depesz.com`](https://explain.depesz.com/).
+- [Pev](http://tatiyants.com/postgres-query-plan-visualization/).
 
 ## Producing query plans
 
@@ -707,7 +707,13 @@ For more information about the available options, run:
 
 ### `#database-lab`
 
-Another tool GitLab employees can use is a chatbot powered by [Joe](https://gitlab.com/postgres-ai/joe) which uses [Database Lab](https://gitlab.com/postgres-ai/database-lab) to instantly provide developers with their own clone of the production database. Joe is available in the [`#database-lab`](https://gitlab.slack.com/archives/CLJMDRD8C) channel on Slack.
+Another tool GitLab employees can use is a chatbot powered by [Joe](https://gitlab.com/postgres-ai/joe)
+which uses [Database Lab](https://gitlab.com/postgres-ai/database-lab) to instantly provide developers
+with their own clone of the production database.
+
+Joe is available in the
+[`#database-lab`](https://gitlab.slack.com/archives/CLJMDRD8C) channel on Slack.
+
 Unlike chatops, it gives you a way to execute DDL statements (like creating indexes and tables) and get query plan not only for `SELECT` but also `UPDATE` and `DELETE`.
 
 For example, in order to test new index you can do the following:

doc/downgrade_ee_to_ce/README.md

@@ -21,7 +21,7 @@ The `JenkinsService` and `GithubService` classes are only available in the Enter
 so if you downgrade to the Community Edition, you'll come across the following
 error:
 
-```
+```plaintext
 Completed 500 Internal Server Error in 497ms (ActiveRecord: 32.2ms)
 
 ActionView::Template::Error (The single-table inheritance mechanism failed to locate the subclass: 'JenkinsService'. This
@@ -32,7 +32,7 @@ use another column for that information.)
 
 or
 
-```
+```plaintext
 Completed 500 Internal Server Error in 497ms (ActiveRecord: 32.2ms)
 
 ActionView::Template::Error (The single-table inheritance mechanism failed to locate the subclass: 'GithubService'. This

doc/gitlab-basics/command-line-commands.md

@@ -43,7 +43,7 @@ The list below is not exhaustive, but contains many of the most commonly used co
 To create a text file from the command line, for example `README.md`, follow these
 steps:
 
-```
+```shell
 touch README.md
 nano README.md
 #### ADD YOUR INFORMATION
@@ -59,14 +59,14 @@ It is easy to delete (remove) a file or directory, but be careful:
 DANGER: **Danger:**
 This will **permanently** delete a file.
 
-```
+```shell
 rm NAME-OF-FILE
 ```
 
 DANGER: **Danger:**
 This will **permanently** delete a directory and **all** of its contents.
 
-```
+```shell
 rm -r NAME-OF-DIRECTORY
 ```
 
@@ -77,14 +77,14 @@ and then execute any of them again, if needed.
 
 First, list the commands you executed previously:
 
-```
+```shell
 history
 ```
 
 Then, choose a command from the list and check the number next to the command (`123`,
 for example) . Execute the same full command with:
 
-```
+```shell
 !123
 ```
 
@@ -95,7 +95,7 @@ need administrator's rights to execute commands that affect the system, or try t
 protected data, for example. You can use `sudo` to execute these commands, but you
 will likely be asked for an administrator password.
 
-```
+```shell
 sudo RESTRICTED-COMMAND
 ```
 

doc/gitlab-basics/create-project.md

@@ -87,8 +87,7 @@ You can improve the existing built-in templates or contribute new ones in the
 
 #### Custom project templates **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6860) in
-[GitLab Premium](https://about.gitlab.com/pricing/) 11.2.
+> [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 for
 quickly starting projects.

doc/install/aws/index.md

@@ -487,7 +487,7 @@ gitlab=# \q
 
 ---
 
-### Configuring GitLab to connect with postgres and Redis
+### Configuring GitLab to connect with PostgreSQL and Redis
 
 Edit the `gitlab.rb` file at `/etc/gitlab/gitlab.rb`
 find the `external_url 'http://gitlab.example.com'` option and change it

doc/install/azure/index.md

@@ -376,7 +376,7 @@ terminal window:
 
 Once the update process has completed, you'll see a message like this:
 
-```
+```plaintext
 Upgrade complete! If your GitLab server is misbehaving try running
 
    sudo gitlab-ctl restart

doc/install/google_cloud_platform/index.md

@@ -90,14 +90,14 @@ here's how you configure GitLab to be aware of the change:
 
 1. Edit the config file of Omnibus GitLab using your favorite text editor:
 
-   ```
+   ```shell
    sudo vim /etc/gitlab/gitlab.rb
    ```
 
 1. Set the `external_url` value to the domain name you wish GitLab to have
    **without** `https`:
 
-   ```
+   ```ruby
    external_url 'http://gitlab.example.com'
    ```
 
@@ -105,7 +105,7 @@ here's how you configure GitLab to be aware of the change:
 
 1. Reconfigure GitLab for the changes to take effect:
 
-   ```
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 

doc/install/installation.md

@@ -47,7 +47,7 @@ If the highest number stable branch is unclear, check the [GitLab blog](https://
 This is the main directory structure you will end up with following the instructions
 of this page:
 
-```
+```plaintext
 |-- home
 |   |-- git
 |       |-- .ssh
@@ -147,7 +147,7 @@ ldd /usr/local/bin/git | grep pcre2
 
 The output should be similar to:
 
-```
+```plaintext
 libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f08461c3000)
 ```
 
@@ -904,7 +904,7 @@ for the changes to take effect.
 
 If you'd like to connect to a Redis server on a non-standard port or a different host, you can configure its connection string via the `config/resque.yml` file.
 
-```
+```yaml
 # example
 production:
   url: redis://redis.example.tld:6379
@@ -912,7 +912,7 @@ production:
 
 If you want to connect the Redis server via socket, use the "unix:" URL scheme and the path to the Redis socket file in the `config/resque.yml` file.
 
-```
+```yaml
 # example
 production:
   url: unix:/path/to/redis/socket
@@ -920,7 +920,7 @@ production:
 
 Also, you can use environment variables in the `config/resque.yml` file:
 
-```
+```yaml
 # example
 production:
   url: <%= ENV.fetch('GITLAB_REDIS_URL') %>
@@ -930,7 +930,7 @@ production:
 
 If you are running SSH on a non-standard port, you must change the GitLab user's SSH config.
 
-```
+```plaintext
 # Add to /home/git/.ssh/config
 host localhost          # Give your setup a name (here: override localhost)
     user git            # Your remote git user

doc/install/openshift_and_gitlab/index.md

@@ -184,7 +184,7 @@ Sometimes though, you may encounter some issues, like OpenShift not running
 when booting up the VM. The web UI may not responding or you may see issues
 when trying to login with `oc`, like:
 
-```
+```plaintext
 The connection to the server 10.2.2.2:8443 was refused - did you specify the right host or port?
 ```
 
@@ -403,7 +403,7 @@ Let's see how to do that using the following steps.
 
    The output will be similar to:
 
-   ```
+   ```plaintext
    NAME                   CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
    gitlab-ce              172.30.243.177   <none>        22/TCP,80/TCP   5d
    gitlab-ce-postgresql   172.30.116.75    <none>        5432/TCP        5d
@@ -436,7 +436,7 @@ Let's see how to do that using the following steps.
 
    which will return something like:
 
-   ```
+   ```plaintext
    NAME          DESIRED   CURRENT   AGE
    gitlab-ce-2   2         2         5d
    ```

doc/install/requirements.md

@@ -147,7 +147,7 @@ Users using PostgreSQL must ensure the `pg_trgm` extension is loaded into every
 GitLab database. This extension can be enabled (using a PostgreSQL super user)
 by running the following query for every database:
 
-```
+```sql
 CREATE EXTENSION pg_trgm;
 ```
 
@@ -170,7 +170,7 @@ If you are using [GitLab Geo](../development/geo.md):
   [postgres_fdw](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
   extension.
 
-```
+```sql
 CREATE EXTENSION postgres_fdw;
 ```
 

doc/integration/azure.md

@@ -67,7 +67,7 @@ To enable the Microsoft Azure OAuth2 OmniAuth provider you must register your ap
 
    For installations from source:
 
-   ```
+   ```yaml
    - { name: 'azure_oauth2',
      args: { client_id: "CLIENT ID",
      client_secret: "CLIENT SECRET",

doc/integration/bitbucket.md

@@ -57,7 +57,7 @@ you to use.
 
    And grant at least the following permissions:
 
-   ```
+   ```plaintext
    Account: Email, Read
    Projects: Read
    Repositories: Read
@@ -77,7 +77,7 @@ you to use.
 
 1. On your GitLab server, open the configuration file:
 
-   ```
+   ```shell
    # For Omnibus packages
    sudo editor /etc/gitlab/gitlab.rb
 

doc/integration/cas.md

@@ -41,7 +41,7 @@ To enable the CAS OmniAuth provider you must register your application with your
 
    For installations from source:
 
-   ```
+   ```yaml
    - { name: 'cas3',
        label: 'cas',
        args: {

doc/integration/elasticsearch.md

 # Elasticsearch integration **(STARTER ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109 "Elasticsearch Merge Request") in GitLab [Starter](https://about.gitlab.com/pricing/) 8.4. Support
-> for [Amazon Elasticsearch](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1305) in GitLab
-> [Starter](https://about.gitlab.com/pricing/) 9.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109 "Elasticsearch Merge Request") in GitLab [Starter](https://about.gitlab.com/pricing/) 8.4.
+> - Support for [Amazon Elasticsearch](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1305) in GitLab [Starter](https://about.gitlab.com/pricing/) 9.0.
 
 This document describes how to set up Elasticsearch with GitLab. Once enabled,
 you'll have the benefit of fast search response times and the advantage of two
@@ -563,7 +562,7 @@ Here are some common pitfalls and how to overcome them:
   If you enabled Elasticsearch before GitLab 8.12 and have not rebuilt indexes you will get
   exception in lots of different cases:
 
-  ```text
+  ```plaintext
   Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
       "error": {
           "root_cause": [{
@@ -587,7 +586,7 @@ Here are some common pitfalls and how to overcome them:
 
 - Exception `Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge`
 
-  ```text
+  ```plaintext
   [413] {"Message":"Request size exceeded 10485760 bytes"}
   ```
 
@@ -619,7 +618,7 @@ Here are some common pitfalls and how to overcome them:
 
 - **I'm getting a `health check timeout: no Elasticsearch node available` error in Sidekiq during the indexing process**
 
-   ```
+   ```plaintext
    Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="health check timeout: no Elasticsearch node available"
    ```
 
@@ -632,5 +631,5 @@ Sometimes there may be issues with your Elasticsearch index data and as such
 GitLab will allow you to revert to "basic search" when there are no search
 results and assuming that basic search is supported in that scope. This "basic
 search" will behave as though you don't have Elasticsearch enabled at all for
-your instance and search using other data sources (ie. Postgres data and Git
+your instance and search using other data sources (ie. PostgreSQL data and Git
 data).

doc/integration/facebook.md

@@ -81,7 +81,7 @@ To enable the Facebook OmniAuth provider you must register your application with
 
    For installations from source:
 
-   ```
+   ```yaml
    - { name: 'facebook', app_id: 'YOUR_APP_ID',
      app_secret: 'YOUR_APP_SECRET' }
    ```

doc/integration/github.md

@@ -69,7 +69,7 @@ Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
 
    For GitHub.com:
 
-   ```
+   ```yaml
    - { name: 'github', app_id: 'YOUR_APP_ID',
      app_secret: 'YOUR_APP_SECRET',
      args: { scope: 'user:email' } }
@@ -77,7 +77,7 @@ Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
 
    For GitHub Enterprise:
 
-   ```
+   ```yaml
    - { name: 'github', app_id: 'YOUR_APP_ID',
      app_secret: 'YOUR_APP_SECRET',
      url: "https://github.example.com/",
@@ -124,7 +124,7 @@ omnibus_gitconfig['system'] = { "http" => ["sslVerify = false"] }
 
 For installation from source:
 
-```
+```yaml
 - { name: 'github', app_id: 'YOUR_APP_ID',
   app_secret: 'YOUR_APP_SECRET',
   url: "https://github.example.com/",
@@ -134,7 +134,7 @@ For installation from source:
 
 You will also need to disable Git SSL verification on the server hosting GitLab.
 
-```
+```shell
 git config --global http.sslVerify false
 ```
 

doc/raketasks/backup_restore.md

@@ -850,7 +850,7 @@ Example: Amazon EBS
 > A GitLab server using Omnibus GitLab hosted on Amazon AWS.
 > An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`.
 > In this case you could make an application backup by taking an EBS snapshot.
-> The backup includes all repositories, uploads and Postgres data.
+> The backup includes all repositories, uploads and PostgreSQL data.
 
 Example: LVM snapshots + rsync
 
@@ -858,7 +858,7 @@ Example: LVM snapshots + rsync
 > Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
 > Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
 > Now we can have a longer running rsync job which will create a consistent replica on the remote server.
-> The replica includes all repositories, uploads and Postgres data.
+> The replica includes all repositories, uploads and PostgreSQL data.
 
 If you are running GitLab on a virtualized server you can possibly also create VM snapshots of the entire GitLab server.
 It is not uncommon however for a VM snapshot to require you to power down the server, so this approach is probably of limited practical use.

doc/topics/autodevops/index.md

@@ -373,7 +373,7 @@ Either way, the resulting Docker image is automatically pushed to the
 
 #### Auto Build using a Dockerfile
 
-If a project's repository contains a `Dockerfile`, Auto Build will use
+If a project's repository contains a `Dockerfile` at its root, Auto Build will use
 `docker build` to create a Docker image.
 
 If you are also using Auto Review Apps and Auto Deploy and choose to provide
@@ -1351,8 +1351,7 @@ service:
 
 #### Deploy policy for staging and production environments
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/160)
-in GitLab 10.8.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/160) in GitLab 10.8.
 
 TIP: **Tip:**
 You can also set this inside your [project's settings](#deployment-strategy).
@@ -1370,8 +1369,7 @@ you when you're ready to manually deploy to production.
 
 #### Deploy policy for canary environments **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/171)
-in GitLab 11.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/171) in GitLab 11.0.
 
 A [canary environment](../../user/project/canary_deployments.md) can be used
 before any changes are deployed to production.

doc/topics/autodevops/upgrading_postgresql.md

@@ -212,7 +212,7 @@ specific environments, e.g. `staging`.
 1. Once connected to the pod, run the following command to restore the database.
 
    - You will be asked for the database password, the default is `testing-password`.
-   - `USERNAME` is the username you have configured for postgres. The default is `user`.
+   - `USERNAME` is the username you have configured for PostgreSQL. The default is `user`.
    - `DATABASE_NAME` is usually the environment name.
 
    ```sh

doc/user/admin_area/settings/account_and_limit_settings.md

@@ -18,7 +18,6 @@ details.
 ## Repository size limit **(STARTER ONLY)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/740) in [GitLab Enterprise Edition 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#limit-project-size-ee).
-> Available in [GitLab Starter](https://about.gitlab.com/pricing/).
 
 Repositories within your GitLab instance can grow quickly, especially if you are
 using LFS. Their size can grow exponentially, rapidly consuming available storage.

doc/user/admin_area/settings/continuous_integration.md

@@ -86,8 +86,7 @@ artifacts, as described in the [troubleshooting documentation](../../../administ
 
 ## Shared Runners pipeline minutes quota **(STARTER ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1078)
-in GitLab Starter 8.16.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1078) in GitLab Starter 8.16.
 
 If you have enabled shared Runners for your GitLab instance, you can limit their
 usage by setting a maximum number of pipeline minutes that a group can use on

doc/user/admin_area/settings/external_authorization.md

@@ -4,10 +4,8 @@ type: reference
 
 # External authorization control **(CORE ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4216) in
-> [GitLab Premium](https://about.gitlab.com/pricing/) 10.6.
-> [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27056) to
-> [GitLab Core](https://about.gitlab.com/pricing/) in 11.10.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4216) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.6.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27056) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.10.
 
 In highly controlled environments, it may be necessary for access policy to be
 controlled by an external service that permits access based on project

doc/user/admin_area/settings/instance_template_repository.md

@@ -4,8 +4,7 @@ type: reference
 
 # Instance template repository **(PREMIUM ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5986) in
-> [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5986) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
 
 ## Overview
 

doc/user/admin_area/settings/usage_statistics.md

@@ -55,10 +55,10 @@ sequenceDiagram
 
 ## Usage Ping **(CORE ONLY)**
 
-> [Introduced][ee-557] in GitLab Enterprise Edition 8.10. More statistics
-[were added][ee-735] in GitLab Enterprise Edition
-8.12. [Moved to GitLab Core][ce-23361] in 9.1. More statistics
-[were added][ee-6602] in GitLab Ultimate 11.2.
+> - [Introduced][ee-557] in GitLab Enterprise Edition 8.10.
+> - More statistics [were added][ee-735] in GitLab Enterprise Edition 8.12.
+> - [Moved to GitLab Core][ce-23361] in 9.1.
+> - More statistics [were added][ee-6602] in GitLab Ultimate 11.2.
 
 GitLab sends a weekly payload containing usage data to GitLab Inc. The usage
 ping uses high-level data to help our product, support, and sales teams. It does

doc/user/application_security/container_scanning/index.md

@@ -4,8 +4,7 @@ type: reference, howto
 
 # Container Scanning **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3672)
-in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3672) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
 
 ## Overview
 
@@ -176,12 +175,12 @@ using environment variables.
 | `CLAIR_OUTPUT`                 | Severity level threshold. Vulnerabilities with severity level higher than or equal to this threshold will be outputted. Supported levels are `Unknown`, `Negligible`, `Low`, `Medium`, `High`, `Critical` and `Defcon1`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | `Unknown`                                                                                                       |
 | `REGISTRY_INSECURE`            | Allow [Klar](https://github.com/optiopay/klar) to access insecure registries (HTTP only). Should only be set to `true` when testing the image locally.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | `"false"`                                                                                                       |
 | `DOCKER_INSECURE`              | Allow [Klar](https://github.com/optiopay/klar) to access secure Docker registries using HTTPS with bad (or self-signed) SSL certificates.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | `"false"`                                                                                                       |
-| `CLAIR_VULNERABILITIES_DB_URL` | (**DEPRECATED - use `CLAIR_DB_CONNECTION_STRING` instead**) This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section.                                      | `clair-vulnerabilities-db`                                                                                      |
-| `CLAIR_DB_CONNECTION_STRING`   | This variable represents the [connection string](https://www.postgresql.org/docs/9.3/libpq-connect.html#AEN39692) to the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) database and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section. The host value for the connection string must match the [alias](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) value of the `Container-Scanning.gitlab-ci.yml` template file, which defaults to `clair-vulnerabilities-db`. | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` |
+| `CLAIR_VULNERABILITIES_DB_URL` | (**DEPRECATED - use `CLAIR_DB_CONNECTION_STRING` instead**) This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section.                                      | `clair-vulnerabilities-db`                                                                                      |
+| `CLAIR_DB_CONNECTION_STRING`   | This variable represents the [connection string](https://www.postgresql.org/docs/9.3/libpq-connect.html#AEN39692) to the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) database and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section. The host value for the connection string must match the [alias](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) value of the `Container-Scanning.gitlab-ci.yml` template file, which defaults to `clair-vulnerabilities-db`. | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` |
 | `CI_APPLICATION_REPOSITORY`    | Docker repository URL for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`                                                                        |
 | `CI_APPLICATION_TAG`           | Docker respository tag for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | `$CI_COMMIT_SHA`                                                                                                |
-| `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation.                                                                                                                                                                                                                                                                                                                                                                      | `arminc/clair-db:latest`                                                                                        |
-| `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
+| `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation.                                                                                                                                                                                                                                                                                                                                                                      | `arminc/clair-db:latest`                                                                                        |
+| `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
 | `DOCKERFILE_PATH`              | The path to the `Dockerfile` to be used for generating remediations. By default, the scanner will look for a file named `Dockerfile` in the root directory of the project, so this variable should only be configured if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details.                                                                                                                                                                                                                                                                                                                                                                          | `Dockerfile`                                                                                                    |
 | `ADDITIONAL_CA_CERT_BUNDLE`   | Bundle of CA certs that you want to trust. | "" |
 

doc/user/application_security/dast/index.md

@@ -4,8 +4,7 @@ type: reference, howto
 
 # Dynamic Application Security Testing (DAST) **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4348)
-in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4348) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
 
 NOTE: **4 of the top 6 attacks were application based.**
 Download our whitepaper,

doc/user/application_security/sast/index.md

@@ -4,8 +4,7 @@ type: reference, howto
 
 # Static Application Security Testing (SAST) **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3775)
-in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3775) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.3.
 
 NOTE: **4 of the top 6 attacks were application based.**
 Download our whitepaper,

doc/user/clusters/applications.md

@@ -351,8 +351,8 @@ file.
 
 #### Jupyter Git Integration
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28783) in GitLab 12.0 for project-level clusters.
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/32512) in GitLab 12.3 for group and instance-level clusters.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28783) in GitLab 12.0 for project-level clusters.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/32512) in GitLab 12.3 for group and instance-level clusters.
 
 When installing JupyterHub onto your Kubernetes cluster, [JupyterLab's Git extension](https://github.com/jupyterlab/jupyterlab-git)
 is automatically provisioned and configured using the authenticated user's:

doc/user/clusters/crossplane.md

@@ -143,9 +143,9 @@ kubectl describe globaladdress.compute.gcp.crossplane.io gitlab-ad-globaladdress
 
 ## Setting up Resource classes
 
-Resource classes are a way of defining a configuration for the required managed service. We will define the Postgres Resource class
+Resource classes are a way of defining a configuration for the required managed service. We will define the PostgreSQL Resource class
 
-- Define a gcp-postgres-standard.yaml resourceclass which contains
+- Define a `gcp-postgres-standard.yaml` resourceclass which contains
 
 1. A default CloudSQLInstanceClass.
 1. A CloudSQLInstanceClass with labels.
@@ -285,4 +285,4 @@ serverCACertificateSha1Fingerprint:   40 bytes
 ## Connect to the PostgreSQL instance
 
 Follow this [GCP guide](https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine) if you
-would like to connect to the newly provisioned Postgres database instance on CloudSQL.
+would like to connect to the newly provisioned PostgreSQL database instance on CloudSQL.

doc/user/incident_management/index.md

@@ -95,8 +95,8 @@ The options are:
 
 ##### View logs
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/201846) in GitLab Ultimate 12.8.
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25455) to [GitLab Core](https://about.gitlab.com/pricing/) 12.9.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/201846) in GitLab Ultimate 12.8.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25455) to [GitLab Core](https://about.gitlab.com/pricing/) 12.9.
 
 This can be useful if you are triaging an application incident and need to
 [explore logs](../project/integrations/prometheus.md#view-logs-ultimate)

doc/user/instance_statistics/dev_ops_score.md

 # DevOps Score
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/30469) in GitLab 9.3.
-> [Renamed from Conversational Development Index](https://gitlab.com/gitlab-org/gitlab/issues/20976) in GitLab 12.6.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/30469) in GitLab 9.3.
+> - [Renamed from Conversational Development Index](https://gitlab.com/gitlab-org/gitlab/issues/20976) in GitLab 12.6.
 
 NOTE: **Note:**
 Your GitLab instance's [usage ping](../admin_area/settings/usage_statistics.md#usage-ping-core-only) must be activated in order to use this feature.

doc/user/instance_statistics/index.md

 # Instance statistics
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/41416)
-in GitLab 11.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/41416) in GitLab 11.2.
 
 Instance statistics gives users or admins access to instance-wide analytics.
 They are accessible to all users by default (GitLab admins can restrict its

doc/user/instance_statistics/user_cohorts.md

 # Cohorts
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/23361)
-in GitLab 9.1.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/23361) in GitLab 9.1.
 
 As a benefit of having the [usage ping active](../admin_area/settings/usage_statistics.md),
 GitLab lets you analyze the users' activities over time of your GitLab installation.

doc/user/markdown.md

@@ -158,8 +158,7 @@ It's possible to generate diagrams and flowcharts from text in GitLab using [Mer
 
 #### Mermaid
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15107) in
-GitLab 10.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15107) in GitLab 10.3.
 
 Visit the [official page](https://mermaidjs.github.io/) for more details. If you're new to using Mermaid or need help identifying issues in your Mermaid code, the [Mermaid Live Editor](https://mermaid-js.github.io/mermaid-live-editor/) is a helpful tool for creating and resolving issues within Mermaid diagrams.
 

doc/user/project/badges.md

 # Badges
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/41174)
-in GitLab 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/41174) in GitLab 10.7.
 
 Badges are a unified way to present condensed pieces of information about your
 projects. They consist of a small image and additionally a URL that the image

doc/user/project/clusters/add_remove_clusters.md

@@ -660,14 +660,14 @@ kubectl create clusterrolebinding permissive-binding \
 
 Amazon EKS doesn't have a default Storage Class out of the box, which means
 requests for persistent volumes will not be automatically fulfilled. As part
-of Auto DevOps, the deployed Postgres instance requests persistent storage,
+of Auto DevOps, the deployed PostgreSQL instance requests persistent storage,
 and without a default storage class it will fail to start.
 
 If a default Storage Class doesn't already exist and is desired, follow Amazon's
 [guide on storage classes](https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html)
 to create one.
 
-Alternatively, disable Postgres by setting the project variable
+Alternatively, disable PostgreSQL by setting the project variable
 [`POSTGRES_ENABLED`](../../../topics/autodevops/#environment-variables) to `false`.
 
 #### Deploy the app to EKS

doc/user/project/clusters/kubernetes_pod_logs.md

 # Kubernetes Logs
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4752) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25455) to [GitLab Core](https://about.gitlab.com/pricing/) 12.9.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4752) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25455) to [GitLab Core](https://about.gitlab.com/pricing/) 12.9.
 
 GitLab makes it easy to view the logs of running pods in [connected Kubernetes clusters](index.md).
 By displaying the logs directly in GitLab, developers can avoid having to manage console tools or jump to a different interface.

doc/user/project/clusters/runbooks/index.md

@@ -120,7 +120,7 @@ VARIABLE_VALUE = project.variables.get('PRIVATE_TOKEN').value
 ### 5. Configure an operation
 
 For this example we'll use the "**Run SQL queries in Notebook**" section in the sample runbook to query
-a postgres database. The first 4 lines of the section define the variables that are required for this query to function.
+a PostgreSQL database. The first 4 lines of the section define the variables that are required for this query to function.
 
 ```sql
 %env DB_USER={project.variables.get('DB_USER').value}
@@ -136,7 +136,7 @@ Create the matching variables in your project's **Settings >> CI/CD >> Variables
 Back in Jupyter, click the "Run SQL queries in Notebook" heading and the click *Run*. The results will be
 displayed in-line as follows:
 
-![postgres query](img/postgres-query.png)
+![PostgreSQL query](img/postgres-query.png)
 
 You can try other operations such as running shell scripts or interacting with a Kubernetes cluster. Visit the
 [Nurtch Documentation](http://docs.nurtch.com/) for more information.

doc/user/project/import/bitbucket_server.md

 # Import your project from Bitbucket Server to GitLab
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20164)
-in GitLab 11.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20164) in GitLab 11.2.
 
 NOTE: **Note:**
 The Bitbucket Server importer does not work with [Bitbucket Cloud](https://bitbucket.org).

doc/user/project/import/phabricator.md

 # Import Phabricator tasks into a GitLab project
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/60562) in
-GitLab 12.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/60562) in GitLab 12.0.
 
 GitLab allows you to import all tasks from a Phabricator instance into
 GitLab issues. The import creates a single project with the

doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md

@@ -6,6 +6,8 @@ description: "Automatic Let's Encrypt SSL certificates for GitLab Pages."
 # GitLab Pages integration with Let's Encrypt
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/28996) in GitLab 12.1. For versions earlier than GitLab 12.1, see the [manual Let's Encrypt instructions](../lets_encrypt_for_gitlab_pages.md).
+
+NOTE: **Note:**
 This feature is in **beta** and may still have bugs. See all the related issues linked from this [issue's description](https://gitlab.com/gitlab-org/gitlab-foss/issues/28996) for more information.
 
 The GitLab Pages integration with Let's Encrypt (LE) allows you

doc/user/project/pages/getting_started/pages_bundled_template.md

@@ -4,8 +4,7 @@ type: reference, howto
 
 # New Pages website from a bundled template
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/47857)
-in GitLab 11.8.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/47857) in GitLab 11.8.
 
 The simplest way to create a GitLab Pages site is to use one of the most
 popular templates, which come already bundled with GitLab and are ready to go.

doc/user/project/releases/index.md

@@ -161,8 +161,7 @@ Release tag. Once the `released_at` date and time has passed, the badge is autom
 
 ## Creating a Release
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32812) in GitLab
-  12.9, Releases can be created directly through the GitLab Releases UI.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32812) in GitLab 12.9, Releases can be created directly through the GitLab Releases UI.
 
 NOTE: **Note:**
 Only users with Developer permissions or higher can create Releases.

doc/user/project/web_ide/index.md

 # Web IDE
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4539) in [GitLab Ultimate][ee] 10.4.
-> [Brought to GitLab Core](https://gitlab.com/gitlab-org/gitlab-foss/issues/44157) in 10.7.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4539) in [GitLab Ultimate][ee] 10.4.
+> - [Brought to GitLab Core](https://gitlab.com/gitlab-org/gitlab-foss/issues/44157) in 10.7.
 
 The Web IDE editor makes it faster and easier to contribute changes to your
 projects by providing an advanced editor with commit staging.

lib/gitlab/kubernetes/helm/install_command.rb

@@ -44,6 +44,7 @@ module Gitlab
         def install_command
           command = ['helm', 'upgrade', name, chart] +
             install_flag +
+            rollback_support_flag +
             reset_values_flag +
             tls_flags_if_remote_tiller +
             optional_version_flag +
@@ -83,6 +84,10 @@ module Gitlab
 
           ['--version', version]
         end
+
+        def rollback_support_flag
+          ['--atomic', '--cleanup-on-fail']
+        end
       end
     end
   end