Add latest changes from gitlab-org/gitlab@master

536aa3a1 · GitLab Bot · 50ae4065 · 536aa3a1 · 536aa3a1 · 536aa3a1
Commit 536aa3a1 authored 5 years ago by GitLab Bot
--- a/doc/administration/geo/replication/updating_the_geo_nodes.md
+++ b/doc/administration/geo/replication/updating_the_geo_nodes.md
@@ -42,7 +42,7 @@ everything is working correctly:
  
 1. Run the Geo raketask on all nodes, everything should be green:
  
-   ```sh
+   ```shell
   sudo gitlab-rake gitlab:geo:check
   ```
  

--- a/doc/administration/geo/replication/using_a_geo_server.md
+++ b/doc/administration/geo/replication/using_a_geo_server.md
@@ -8,7 +8,7 @@ Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS)
  
 Example of the output you will see when pushing to a **secondary** node:
  
-```bash
+```shell
 $ git push
 remote:
 remote: You're pushing to a Geo secondary. We'll help you by proxying this

--- a/doc/administration/geo/replication/version_specific_updates.md
+++ b/doc/administration/geo/replication/version_specific_updates.md
@@ -16,7 +16,7 @@ This update will occur even if major PostgreSQL updates are disabled.
 Before [refreshing Foreign Data Wrapper during a Geo HA upgrade](https://docs.gitlab.com/omnibus/update/README.html#run-post-deployment-migrations-and-checks),
 restart the Geo tracking database:
  
-```sh
+```shell
 sudo gitlab-ctl restart geo-postgresql
 ```
  
@@ -31,7 +31,7 @@ for the recommended procedure.
  
 This can be temporarily disabled by running the following before updating:
  
-```sh
+```shell
 sudo touch /etc/gitlab/disable-postgresql-upgrade
 ```
  
@@ -41,7 +41,7 @@ Before 10.8, broadcast messages would not propagate without flushing
 the cache on the **secondary** nodes. This has been fixed in 10.8, but
 requires one last cache flush on each **secondary** node:
  
-```sh
+```shell
 sudo gitlab-rake cache:clear
 ```
  
@@ -55,7 +55,7 @@ authentication method.
  
 1. **(primary)** Login to your **primary** node and run:
  
-   ```sh
+   ```shell
   gitlab-ctl pg-password-md5 gitlab
   # Enter password: <your_password_here>
   # Confirm password: <your_password_here>
@@ -82,7 +82,7 @@ authentication method.
  
 1. **(primary)** Reconfigure and restart:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   ```
@@ -113,7 +113,7 @@ authentication method.
  
 1. **(secondary)** Reconfigure and restart:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   ```
@@ -129,7 +129,7 @@ contents of `/etc/gitlab/gitlab-secrets.json` on each **secondary** node with th
 contents of `/etc/gitlab/gitlab-secrets.json` on the **primary** node, then run the
 following command on each **secondary** node:
  
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
  
@@ -228,7 +228,7 @@ following to clean this up.
  
 On the **secondary** Geo nodes, run as root:
  
-```sh
+```shell
 mv /var/opt/gitlab/gitlab-rails/working /var/opt/gitlab/gitlab-rails/working.old
 mkdir /var/opt/gitlab/gitlab-rails/working
 chmod 700 /var/opt/gitlab/gitlab-rails/working
@@ -240,7 +240,7 @@ You may delete `/var/opt/gitlab/gitlab-rails/working.old` any time.
 Once this is done, we advise restarting GitLab on the **secondary** nodes for the
 new working directory to be used:
  
-```sh
+```shell
 sudo gitlab-ctl restart
 ```
  
@@ -289,7 +289,7 @@ is prepended with the relevant node for better clarity:
 1. **(secondary)** Make a backup of the `recovery.conf` file on **all**
   **secondary** nodes to preserve PostgreSQL's credentials:
  
-   ```sh
+   ```shell
   sudo cp /var/opt/gitlab/postgresql/data/recovery.conf /var/opt/gitlab/
   ```
  
@@ -301,7 +301,7 @@ is prepended with the relevant node for better clarity:
   stop all services except `postgresql` as we will use it to re-initialize the
   **secondary** node's database:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl stop
   sudo gitlab-ctl start postgresql
   ```
@@ -310,19 +310,19 @@ is prepended with the relevant node for better clarity:
  
   1. **(secondary)**  Stop all services:
  
-      ```sh
+      ```shell
      sudo gitlab-ctl stop
      ```
  
   1. **(secondary)** Prevent running database migrations:
  
-      ```sh
+      ```shell
      sudo touch /etc/gitlab/skip-auto-migrations
      ```
  
   1. **(secondary)** Move the old database to another directory:
  
-      ```sh
+      ```shell
      sudo mv /var/opt/gitlab/postgresql{,.bak}
      ```
  
@@ -331,33 +331,33 @@ is prepended with the relevant node for better clarity:
  
   1. **(secondary)** Make sure all services are up:
  
-      ```sh
+      ```shell
      sudo gitlab-ctl start
      ```
  
   1. **(secondary)** Reconfigure GitLab:
  
-      ```sh
+      ```shell
      sudo gitlab-ctl reconfigure
      ```
  
   1. **(secondary)** Run the PostgreSQL upgrade command:
  
-      ```sh
+      ```shell
      sudo gitlab-ctl pg-upgrade
      ```
  
   1. **(secondary)** See the stored credentials for the database that you will
      need to re-initialize the replication:
  
-      ```sh
+      ```shell
      sudo grep -s primary_conninfo /var/opt/gitlab/recovery.conf
      ```
  
   1. **(secondary)** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the
      embedded paths if necessary:
  
-      ```bash
+      ```shell
      #!/bin/bash
  
      PORT="5432"
@@ -404,19 +404,19 @@ is prepended with the relevant node for better clarity:
   1. **(secondary)** Run the recovery script using the credentials from the
      previous step:
  
-      ```sh
+      ```shell
      sudo bash /tmp/replica.sh
      ```
  
   1. **(secondary)** Reconfigure GitLab:
  
-      ```sh
+      ```shell
      sudo gitlab-ctl reconfigure
      ```
  
   1. **(secondary)** Start all services:
  
-      ```sh
+      ```shell
      sudo gitlab-ctl start
      ```
  
@@ -425,7 +425,7 @@ is prepended with the relevant node for better clarity:
 1. **(primary)** After all **secondary** nodes are updated, start all services in
   **primary** node:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl start
   ```
  
@@ -437,7 +437,7 @@ and it is required since 10.0.
  
 1. Run database migrations on tracking database:
  
-   ```sh
+   ```shell
   sudo gitlab-rake geo:db:migrate
   ```
  

--- a/doc/administration/git_annex.md
+++ b/doc/administration/git_annex.md
@@ -96,7 +96,7 @@ one is located in `config.yml` of GitLab Shell.
 Here is an example workflow of uploading a very large file and then checking it
 into your Git repository:
  
-```bash
+```shell
 git clone git@example.com:group/project.git
  
 git annex init 'My Laptop'       # initialize the annex project and give an optional description
@@ -165,7 +165,7 @@ repository.
  
 Downloading a single large file is also very simple:
  
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
  
 git annex sync             # sync Git branches but not the large file
@@ -174,7 +174,7 @@ git annex get debian.iso   # download the large file
  
 To download all files:
  
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
  
 git annex sync --content  # sync Git branches and download all the large files

--- a/doc/administration/git_protocol.md
+++ b/doc/administration/git_protocol.md
@@ -45,7 +45,7 @@ AcceptEnv GIT_PROTOCOL
  
 Once configured, restart the SSH daemon. In Ubuntu, run:
  
-```sh
+```shell
 sudo service ssh restart
 ```
  
@@ -54,7 +54,7 @@ sudo service ssh restart
 In order to use the new protocol, clients need to either pass the configuration
 `-c protocol.version=2` to the Git command, or set it globally:
  
-```sh
+```shell
 git config --global protocol.version 2
 ```
  
@@ -62,7 +62,7 @@ git config --global protocol.version 2
  
 Verify Git v2 is used by the client:
  
-```sh
+```shell
 GIT_TRACE_CURL=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | grep Git-Protocol
 ```
  
@@ -74,13 +74,13 @@ You should see that the `Git-Protocol` header is sent:
  
 Verify Git v2 is used by the server:
  
-```sh
+```shell
 GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | head
 ```
  
 Example response using Git protocol v2:
  
-```sh
+```shell
 $ GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | head
 10:42:50.574485 pkt-line.c:80           packet:          git< # service=git-upload-pack
 10:42:50.574653 pkt-line.c:80           packet:          git< 0000
@@ -98,7 +98,7 @@ $ GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-ins
  
 Verify Git v2 is used by the client:
  
-```sh
+```shell
 GIT_SSH_COMMAND="ssh -v" git -c protocol.version=2 ls-remote ssh://your-gitlab-instance.com:group/repo.git 2>&1 |grep GIT_PROTOCOL
 ```
  

--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -309,7 +309,7 @@ can read and write to `/mnt/gitlab/storage2`.
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. Tail the logs to see the requests:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl tail gitaly
   ```
  
@@ -343,7 +343,7 @@ can read and write to `/mnt/gitlab/storage2`.
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
 1. Tail the logs to see the requests:
  
-   ```sh
+   ```shell
   tail -f /home/git/gitlab/log/gitaly.log
   ```
  
@@ -435,7 +435,7 @@ To configure Gitaly with TLS:
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on client node(s).
 1. On the Gitaly server, create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
  
-   ```sh
+   ```shell
   sudo mkdir -p /etc/gitlab/ssl
   sudo chmod 755 /etc/gitlab/ssl
   sudo cp key.pem cert.pem /etc/gitlab/ssl/
@@ -491,7 +491,7 @@ To configure Gitaly with TLS:
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) on client node(s).
 1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
  
-   ```sh
+   ```shell
   sudo mkdir -p /etc/gitlab/ssl
   sudo chmod 700 /etc/gitlab/ssl
   sudo cp key.pem cert.pem /etc/gitlab/ssl/
@@ -856,7 +856,7 @@ your GitLab / Gitaly server already at `/opt/gitlab/embedded/bin/gitaly-debug`.
 If you're investigating an older GitLab version you can compile this
 tool offline and copy the executable to your server:
  
-```sh
+```shell
 git clone https://gitlab.com/gitlab-org/gitaly.git
 cd cmd/gitaly-debug
 GOOS=linux GOARCH=amd64 go build -o gitaly-debug
@@ -864,7 +864,7 @@ GOOS=linux GOARCH=amd64 go build -o gitaly-debug
  
 To see the help page of `gitaly-debug` for a list of supported sub-commands, run:
  
-```sh
+```shell
 gitaly-debug -h
 ```
  
@@ -887,7 +887,7 @@ default level is `WARN`.
  
 You can run a GRPC trace with:
  
-```sh
+```shell
 GRPC_TRACE=all GRPC_VERBOSITY=DEBUG sudo gitlab-rake gitlab:gitaly:check
 ```
  
@@ -925,7 +925,7 @@ Confirm the following are all true:
 - When any user performs a `git push` to any repository on this Gitaly node, it
  fails with the following error (note the `401 Unauthorized`):
  
-  ```sh
+  ```shell
  remote: GitLab: 401 Unauthorized
  To <REMOTE_URL>
  ! [remote rejected] branch-name -> branch-name (pre-receive hook declined)
@@ -939,7 +939,7 @@ Confirm the following are all true:
 - When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors
  when reaching the `/api/v4/internal/allowed` endpoint:
  
-  ```sh
+  ```shell
  # api_json.log
  {
    "time": "2019-07-18T00:30:14.967Z",
@@ -1009,7 +1009,7 @@ If you are having trouble connecting to a Gitaly node with command line (CLI) to
  
 Verify that you can reach Gitaly via TCP:
  
-```bash
+```shell
 sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]
 ```
  
@@ -1019,7 +1019,7 @@ If you use proxy servers in your command line environment, such as Bash, these c
  
 If you use Bash or a compatible command line environment, run the following commands to determine whether you have proxy servers configured:
  
-```bash
+```shell
 echo $http_proxy
 echo $https_proxy
 ```
@@ -1028,7 +1028,7 @@ If either of these variables have a value, your Gitaly CLI connections may be ge
  
 To remove the proxy setting, run the following commands (depending on which variables had values):
  
-```bash
+```shell
 unset http_proxy
 unset https_proxy
 ```

--- a/doc/administration/high_availability/consul.md
+++ b/doc/administration/high_availability/consul.md
@@ -58,7 +58,7 @@ On each Consul node perform the following:
 Before moving on, make sure Consul is configured correctly. Run the following
 command to verify all server nodes are communicating:
  
-```sh
+```shell
 /opt/gitlab/embedded/bin/consul members
 ```
  

--- a/doc/administration/high_availability/database.md
+++ b/doc/administration/high_availability/database.md
@@ -46,7 +46,7 @@ deploy the bundled PostgreSQL.
   and confirmation. Use the value that is output by this command in the next
   step as the value of `POSTGRESQL_PASSWORD_HASH`.
  
-   ```sh
+   ```shell
   sudo gitlab-ctl pg-password-md5 gitlab
   ```
  
@@ -202,7 +202,7 @@ When using default setup, minimum configuration requires:
 - `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair.
   Can be generated with:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME
   ```
  
@@ -245,7 +245,7 @@ We will need the following password information for the application's database u
 - `POSTGRESQL_PASSWORD_HASH`. This is a hash generated out of the username/password pair.
  Can be generated with:
  
-  ```sh
+  ```shell
  sudo gitlab-ctl pg-password-md5 POSTGRESQL_USERNAME
  ```
  
@@ -258,7 +258,7 @@ When using default setup, minimum configuration requires:
 - `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of PgBouncer username/password pair.
  Can be generated with:
  
-  ```sh
+  ```shell
  sudo gitlab-ctl pg-password-md5 PGBOUNCER_USERNAME
  ```
  
@@ -376,13 +376,13 @@ Select one node as a primary node.
  
 1. Open a database prompt:
  
-   ```sh
+   ```shell
   gitlab-psql -d gitlabhq_production
   ```
  
 1. Enable the `pg_trgm` extension:
  
-   ```sh
+   ```shell
   CREATE EXTENSION pg_trgm;
   ```
  
@@ -390,7 +390,7 @@ Select one node as a primary node.
  
 1. Verify the cluster is initialized with one node:
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr cluster show
   ```
  
@@ -411,7 +411,7 @@ Select one node as a primary node.
  
 1. Set up the repmgr standby:
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr standby setup MASTER_NODE_NAME
   ```
  
@@ -436,7 +436,7 @@ Select one node as a primary node.
  
 1. Verify the node now appears in the cluster:
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr cluster show
   ```
  
@@ -457,7 +457,7 @@ Before moving on, make sure the databases are configured correctly. Run the
 following command on the **primary** node to verify that replication is working
 properly:
  
-```sh
+```shell
 gitlab-ctl repmgr cluster show
 ```
  
@@ -475,7 +475,7 @@ If the 'Role' column for any node says "FAILED", check the
  
 Also, check that the check master command works successfully on each node:
  
-```sh
+```shell
 su - gitlab-consul
 gitlab-ctl repmgr-check-master || echo 'This node is a standby repmgr node'
 ```
@@ -512,7 +512,7 @@ attributes set, but the following need to be set.
  
 Ensure that all migrations ran:
  
-```sh
+```shell
 gitlab-rake gitlab:db:configure
 ```
  
@@ -702,7 +702,7 @@ After deploying the configuration follow these steps:
  
   Enable the `pg_trgm` extension
  
-   ```sh
+   ```shell
   gitlab-psql -d gitlabhq_production
   ```
  
@@ -714,7 +714,7 @@ After deploying the configuration follow these steps:
  
   Make this node a standby of the primary
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr standby setup 10.6.0.21
   ```
  
@@ -722,7 +722,7 @@ After deploying the configuration follow these steps:
  
   Make this node a standby of the primary
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr standby setup 10.6.0.21
   ```
  
@@ -730,13 +730,13 @@ After deploying the configuration follow these steps:
  
   Set `gitlab-consul` user's PgBouncer password to `toomanysecrets`
  
-   ```sh
+   ```shell
   gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
   ```
  
   Run database migrations
  
-   ```sh
+   ```shell
   gitlab-rake gitlab:db:configure
   ```
  
@@ -863,7 +863,7 @@ If you need to failover manually, you have two options:
  
 Run:
  
-```sh
+```shell
 gitlab-ctl stop postgresql
 ```
  
@@ -875,14 +875,14 @@ standby nodes.
 1. Ensure the old master node is not still active.
 1. Login to the server that should become the new master and run:
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr standby promote
   ```
  
 1. If there are any other standby servers in the cluster, have them follow
   the new master server:
  
-   ```sh
+   ```shell
   gitlab-ctl repmgr standby follow NEW_MASTER
   ```
  
@@ -894,7 +894,7 @@ after it has been restored to service.
 - If you want to remove the node from the cluster, on any other node in the
  cluster, run:
  
-  ```sh
+  ```shell
  gitlab-ctl repmgr standby unregister --node=X
  ```
  
@@ -902,7 +902,7 @@ after it has been restored to service.
  
  To find this, you can use:
  
-  ```sh
+  ```shell
  awk -F = '$1 == "node" { print $2 }' /var/opt/gitlab/postgresql/repmgr.conf
  ```
  
@@ -914,13 +914,13 @@ after it has been restored to service.
  
  Then you will use this id to unregister the node:
  
-  ```sh
+  ```shell
  gitlab-ctl repmgr standby unregister --node=959789412
  ```
  
 - To add the node as a standby server:
  
-  ```sh
+  ```shell
  gitlab-ctl repmgr standby follow NEW_MASTER
  gitlab-ctl restart repmgrd
  ```
@@ -972,7 +972,7 @@ the previous section:
 1. On the current master node, create a password for the `gitlab` and
   `gitlab_repmgr` user:
  
-   ```sh
+   ```shell
   gitlab-psql -d template1
   template1=# \password gitlab_repmgr
   Enter password: ****
@@ -992,7 +992,7 @@ the previous section:
   1. Create a `.pgpass` file. Enter the `gitlab_repmgr` password twice to
      when asked:
  
-      ```sh
+      ```shell
      gitlab-ctl write-pgpass --user gitlab_repmgr --hostuser gitlab-psql --database '*'
      ```
  

--- a/doc/administration/high_availability/gitlab.md
+++ b/doc/administration/high_availability/gitlab.md
@@ -101,7 +101,7 @@ these additional steps before proceeding with GitLab installation.
  
 On the first application server, run:
  
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
  

--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -55,7 +55,7 @@ NOTE: **Note:** From GitLab 12.1, it will automatically be detected if Rugged ca
  
 If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using:
  
-```sh
+```shell
 sudo gitlab-rake gitlab:features:unset_rugged
 ```
  
@@ -82,7 +82,7 @@ on an Linux NFS server, do the following:
  
 1. On the NFS server, run:
  
-   ```sh
+   ```shell
   echo 0 > /proc/sys/fs/leases-enable
   sysctl -w fs.leases-enable=0
   ```
@@ -186,7 +186,7 @@ single NFS mount point as you normally would in `/etc/fstab`. Let's assume your
 NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in
 `/etc/fstab`:
  
-```bash
+```shell
 /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
 /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
 /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0

--- a/doc/administration/high_availability/nfs_host_client_setup.md
+++ b/doc/administration/high_availability/nfs_host_client_setup.md
@@ -27,7 +27,7 @@ Using EFS may negatively impact performance. Please review the [relevant documen
  
 Installing the nfs-kernel-server package allows you to share directories with the clients running the GitLab application.
  
-```sh
+```shell
 apt-get update
 apt-get install nfs-kernel-server
 ```
@@ -47,7 +47,7 @@ In this setup we will share the home directory on the host with the client. Edit
 Restart the NFS server after making changes to the `exports` file for the changes
 to take effect.
  
-```sh
+```shell
 systemctl restart nfs-kernel-server
 ```
  
@@ -64,7 +64,7 @@ inside your HA environment to the NFS server configured above.
 The nfs-common provides NFS functionality without installing server components which
 we don't need running on the application nodes.
  
-```sh
+```shell
 apt-get update
 apt-get install nfs-common
 ```
@@ -76,14 +76,14 @@ Please note that if your mount point directory contains any files they will be h
 once the remote shares are mounted. An empty/new directory on the client is recommended
 for this purpose.
  
-```sh
+```shell
 mkdir -p /nfs/home
 ```
  
 Confirm that the mount point works by mounting it on the client and checking that
 it is mounted with the command below:
  
-```sh
+```shell
 mount <host_ip_address>:/home
 df -h
 ```
@@ -134,7 +134,7 @@ Check that NFS traffic from the client is allowed by the firewall on the host by
 the command: `sudo ufw status`. If it's being blocked, then you can allow traffic from a specific
 client with the command below.
  
-```sh
+```shell
 sudo ufw allow from <client-ip-address> to any port nfs
 ```
  

--- a/doc/administration/high_availability/pgbouncer.md
+++ b/doc/administration/high_availability/pgbouncer.md
@@ -57,7 +57,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
 1. Create a `.pgpass` file so Consul is able to
   reload PgBouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
  
-   ```sh
+   ```shell
   gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
   ```
  
@@ -65,7 +65,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
  
 1. Ensure each node is talking to the current master:
  
-   ```sh
+   ```shell
   gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
   ```
  
@@ -77,7 +77,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
  
 1. Once the console prompt is available, run the following queries:
  
-   ```sh
+   ```shell
   show databases ; show clients ;
   ```
  

--- a/doc/administration/high_availability/redis.md
+++ b/doc/administration/high_availability/redis.md
@@ -8,8 +8,10 @@ type: reference
  
 The following are the requirements for providing your own Redis instance:
  
- Redis version 2.8 or higher. Version 3.2 or higher is recommend as this is
-  what ships with the GitLab Omnibus package.
+- GitLab 12.0 and later requires Redis version 3.2 or higher. Version 3.2 or higher is recommend as this is
+  what ships with the GitLab Omnibus package. Older Redis versions do not
+  support an optional count argument to SPOP which is now required for
+  [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
 - Standalone Redis or Redis high availability with Sentinel are supported. Redis
  Cluster is not supported.
 - Managed Redis from cloud providers such as AWS Elasticache will work. If these
@@ -978,7 +980,7 @@ To make sure your configuration is correct:
  
 1. To simulate a failover on master Redis, SSH into the Redis server and run:
  
-   ```bash
+   ```shell
   # port must match your master redis port, and the sleep time must be a few seconds bigger than defined one
    redis-cli -h localhost -p 6379 DEBUG sleep 20
   ```

--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -102,14 +102,14 @@ for a real-world example of this exploit.
  
 1. Reconfigure GitLab for the changes to take effect:
  
-   ```sh
+   ```shell
   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   ```
  
 1. Verify that everything is configured correctly:
  
-   ```sh
+   ```shell
   sudo gitlab-rake gitlab:incoming_email:check
   ```
  
@@ -119,7 +119,7 @@ Reply by email should now be working.
  
 1. Go to the GitLab installation directory:
  
-   ```sh
+   ```shell
   cd /home/git/gitlab
   ```
  
@@ -128,20 +128,20 @@ Reply by email should now be working.
  
 1. Enable `mail_room` in the init script at `/etc/default/gitlab`:
  
-   ```sh
+   ```shell
   sudo mkdir -p /etc/default
   echo 'mail_room_enabled=true' | sudo tee -a /etc/default/gitlab
   ```
  
 1. Restart GitLab:
  
-   ```sh
+   ```shell
   sudo service gitlab restart
   ```
  
 1. Verify that everything is configured correctly:
  
-   ```sh
+   ```shell
   sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production
   ```
  

--- a/doc/administration/integration/plantuml.md
+++ b/doc/administration/integration/plantuml.md
@@ -15,7 +15,7 @@ server that will generate the diagrams.
  
 With Docker, you can just run a container like this:
  
-```sh
+```shell
 docker run -d --name plantuml -p 8080:8080 plantuml/plantuml-server:tomcat
 ```
  
@@ -50,7 +50,7 @@ own PlantUML server is easy in Debian/Ubuntu distributions using Tomcat.
  
 First you need to create a `plantuml.war` file from the source code:
  
-```sh
+```shell
 sudo apt-get install graphviz openjdk-8-jdk git-core maven
 git clone https://github.com/plantuml/plantuml-server.git
 cd plantuml-server
@@ -101,7 +101,7 @@ nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n rewrite ^/-/(p
  
 To activate the changes, run the following command:
  
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
  

--- a/doc/administration/invalidate_markdown_cache.md
+++ b/doc/administration/invalidate_markdown_cache.md
@@ -11,6 +11,6 @@ increasing the `local_markdown_version` setting in application settings.  This c
 be done by [changing the application settings through
 the API](../api/settings.md#change-application-settings):
  
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?local_markdown_version=<increased_number>
 ```
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -156,7 +156,7 @@ _The artifacts are stored by default in
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
  
-   ```bash
+   ```shell
   gitlab-rake gitlab:artifacts:migrate
   ```
  
@@ -184,7 +184,7 @@ _The artifacts are stored by default in
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
  
-   ```bash
+   ```shell
   sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
   ```
  
@@ -239,7 +239,7 @@ you can flip the feature flag from a Rails console.
  
 1. Enter the Rails console:
  
-   ```sh
+   ```shell
   sudo gitlab-rails console
   ```
  
@@ -253,7 +253,7 @@ you can flip the feature flag from a Rails console.
  
 1. Enter the Rails console:
  
-   ```sh
+   ```shell
   cd /home/git/gitlab
   RAILS_ENV=production sudo -u git -H bundle exec rails console
   ```

--- a/doc/administration/job_logs.md
+++ b/doc/administration/job_logs.md
@@ -100,7 +100,7 @@ Here is the detailed data flow:
  
 The following commands are to be issued in a Rails console:
  
-```sh
+```shell
 # Omnibus GitLab
 gitlab-rails console
  

--- a/doc/administration/lfs/lfs_administration.md
+++ b/doc/administration/lfs/lfs_administration.md
@@ -138,13 +138,13 @@ There are two ways to manually do the same thing as automatic uploading (describ
  
 **Option 1: rake task**
  
-```sh
+```shell
 rake gitlab:lfs:migrate
 ```
  
 **Option 2: rails console**
  
-```sh
+```shell
 $ sudo gitlab-rails console            # Login to rails console
  
 > # Upload LFS files manually
@@ -178,7 +178,7 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`:
 1. Save the file and [reconfigure GitLab]s for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
  
-   ```bash
+   ```shell
   gitlab-rake gitlab:lfs:migrate
   ```
  
@@ -214,7 +214,7 @@ For source installations the settings are nested under `lfs:` and then
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
  
-   ```bash
+   ```shell
   sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production
   ```
  

--- a/doc/administration/lfs/manage_large_binaries_with_git_lfs.md
+++ b/doc/administration/lfs/manage_large_binaries_with_git_lfs.md
@@ -50,7 +50,7 @@ Lets take a look at the workflow when you need to check large files into your Gi
 repository with Git LFS. For example, if you want to upload a very large file and
 check it into your Git repository:
  
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
 git lfs install                       # initialize the Git LFS project
 git lfs track "*.iso"                 # select the file extensions that you want to treat as large files
@@ -59,7 +59,7 @@ git lfs track "*.iso"                 # select the file extensions that you want
 Once a certain file extension is marked for tracking as a LFS object you can use
 Git as usual without having to redo the command to track a file with the same extension:
  
-```bash
+```shell
 cp ~/tmp/debian.iso ./                # copy a large file into the current directory
 git add .                             # add the large file to the project
 git commit -am "Added Debian iso"     # commit the file meta data
@@ -69,7 +69,7 @@ git push origin master                # sync the git repo and large file to the
 **Make sure** that `.gitattributes` is tracked by Git. Otherwise Git
 LFS will not be working properly for people cloning the project:
  
-```bash
+```shell
 git add .gitattributes
 ```
  
@@ -78,14 +78,14 @@ LFS-tracked files and clones them via HTTP. If you performed the `git clone`
 command with a SSH URL, you have to enter your GitLab credentials for HTTP
 authentication.
  
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
 ```
  
 If you already cloned the repository and you want to get the latest LFS object
 that are on the remote repository, eg. for a branch from origin:
  
-```bash
+```shell
 git lfs fetch origin master
 ```
  
@@ -101,14 +101,14 @@ The first thing to do before using File Locking is to tell Git LFS which
 kind of files are lockable. The following command will store PNG files
 in LFS and flag them as lockable:
  
-```bash
+```shell
 git lfs track "*.png" --lockable
 ```
  
 After executing the above command a file named `.gitattributes` will be
 created or updated with the following content:
  
-```bash
+```shell
 *.png filter=lfs diff=lfs merge=lfs -text lockable
 ```
  
@@ -116,7 +116,7 @@ You can also register a file type as lockable without using LFS
 (In order to be able to lock/unlock a file you need a remote server that implements the  LFS File Locking API),
 in order to do that you can edit the `.gitattributes` file manually:
  
-```bash
+```shell
 *.pdf lockable
 ```
  
@@ -128,14 +128,14 @@ need to lock the file before editing it.
  
 Once you're ready to edit your file you need to lock it first:
  
-```bash
+```shell
 git lfs lock images/banner.png
 Locked images/banner.png
 ```
  
 This will register the file as locked in your name on the server:
  
-```bash
+```shell
 git lfs locks
 images/banner.png  joe   ID:123
 ```
@@ -143,13 +143,13 @@ images/banner.png  joe   ID:123
 Once you have pushed your changes, you can unlock the file so others can
 also edit it:
  
-```bash
+```shell
 git lfs unlock images/banner.png
 ```
  
 You can also unlock by id:
  
-```bash
+```shell
 git lfs unlock --id=123
 ```
  
@@ -157,7 +157,7 @@ If for some reason you need to unlock a file that was not locked by you,
 you can use the `--force` flag as long as you have a `maintainer` access on
 the project:
  
-```bash
+```shell
 git lfs unlock --id=123 --force
 ```
  
@@ -183,7 +183,7 @@ available to the project anymore. Probably the object was removed from the serve
 Git LFS will log the failures into a log file.
 To view this log file, while in project directory:
  
-```bash
+```shell
 git lfs logs last
 ```
  
@@ -215,7 +215,7 @@ This behaviour is caused by Git LFS using HTTPS connections by default when a
  
 To prevent this from happening, set the lfs url in project Git config:
  
-```bash
+```shell
 git config --add lfs.url "http://gitlab.example.com/group/project.git/info/lfs"
 ```
  
@@ -235,7 +235,7 @@ you use. This is described in [Git credentials man pages](https://git-scm.com/do
 For example, you can tell Git to remember the password for a period of time in
 which you expect to push the objects:
  
-```bash
+```shell
 git config --global credential.helper 'cache --timeout=3600'
 ```