Add latest changes from gitlab-org/gitlab@master

doc/administration/auth/authentiq.md

@@ -14,13 +14,13 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
    For omnibus installation
-   ```sh
+   ```shell
    sudo editor /etc/gitlab/gitlab.rb
    ```
    For installations from source:
-   ```sh
+   ```shell
    sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
    ```

doc/administration/auth/crowd.md

@@ -20,13 +20,13 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
    **Omnibus:**
-   ```sh
+   ```shell
      sudo editor /etc/gitlab/gitlab.rb
    ```
    **Source:**
-   ```sh
+   ```shell
      cd /home/git/gitlab
      sudo -u git -H editor config/gitlab.yml

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -149,7 +149,7 @@ You can use the [`AdFind`](https://social.technet.microsoft.com/wiki/contents/ar
 You can use the filter `objectclass=*` to return all directory objects.
-```sh
+```shell
 adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -up Password1 -b "OU=GitLab INT,DC=GitLab,DC=org" -f (objectClass=*)
 ```
@@ -157,7 +157,7 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
 You can also retrieve a single object by **specifying** the object name or full **DN**. In this example we specify the object name only `CN=Leroy Fox`.
-```sh
+```shell
 adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -up Password1 -b "OU=GitLab INT,DC=GitLab,DC=org" -f (&(objectcategory=person)(CN=Leroy Fox))”
 ```
@@ -169,7 +169,7 @@ You can use the `ldapsearch` utility (on Unix based systems) to test that your L
 You can use the filter `objectclass=*` to return all directory objects.
-```sh
+```shell
 ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" \
 -w Password1 -p 636 -h ad.example.org \
 -b "OU=GitLab INT,DC=GitLab,DC=org" -Z \
@@ -180,7 +180,7 @@ ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" \
 You can also retrieve a single object by **specifying** the object name or full **DN**. In this example we specify the object name only `CN=Leroy Fox`.
-```sh
+```shell
 ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -w Password1 -p 389 -h ad.example.org -b "OU=GitLab INT,DC=GitLab,DC=org" -Z -s sub "CN=Leroy Fox"
 ```

doc/administration/auth/jwt.md

@@ -11,13 +11,13 @@ JWT will provide you with a secret key for you to use.
    For Omnibus GitLab:
-   ```sh
+   ```shell
    sudo editor /etc/gitlab/gitlab.rb
    ```
    For installations from source:
-   ```sh
+   ```shell
    cd /home/git/gitlab
    sudo -u git -H editor config/gitlab.yml
    ```

doc/administration/auth/ldap-ee.md

@@ -465,7 +465,7 @@ step of the sync.
 1. Start a Rails console:
-   ```bash
+   ```shell
    # For Omnibus installations
    sudo gitlab-rails console
@@ -540,7 +540,7 @@ statements.
 Indicates the point where syncing actually begins:
-```bash
+```shell
 Started syncing all providers for 'my_group' group
 ```
@@ -551,7 +551,7 @@ log entries like this - one for each LDAP group. If you don't see an LDAP user
 DN in this log entry, LDAP is not returning the user when we do the lookup.
 Verify the user is actually in the LDAP group.
-```bash
+```shell
 Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
 "uid=mary0,ou=people,dc=example,dc=com", "uid=john1,ou=people,dc=example,dc=com",
 "uid=mary1,ou=people,dc=example,dc=com", "uid=john2,ou=people,dc=example,dc=com",
@@ -571,7 +571,7 @@ NOTE: **Note:**
 10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
 and 50 is 'Owner'.
-```bash
+```shell
 Resolved 'my_group' group member access: {"uid=john0,ou=people,dc=example,dc=com"=>30,
 "uid=mary0,ou=people,dc=example,dc=com"=>30, "uid=john1,ou=people,dc=example,dc=com"=>30,
 "uid=mary1,ou=people,dc=example,dc=com"=>30, "uid=john2,ou=people,dc=example,dc=com"=>30,
@@ -588,7 +588,7 @@ If you think a particular user should already exist in GitLab, but you're seeing
 this entry, it could be due to a mismatched DN stored in GitLab. See
 [User DN has changed](#User-DN-has-changed) to update the user's LDAP identity.
-```bash
+```shell
 User with DN `uid=john0,ou=people,dc=example,dc=com` should have access
 to 'my_group' group but there is no user in GitLab with that
 identity. Membership will be updated once the user signs in for
@@ -597,6 +597,6 @@ the first time.
 Finally, the following entry says syncing has finished for this group:
-```bash
+```shell
 Finished syncing all providers for 'my_group' group
 ```

doc/administration/auth/ldap.md

@@ -564,7 +564,7 @@ This example uses `ldapsearch` and assumes you are using ActiveDirectory. The
 following query returns the login names of the users that will be allowed to
 log in to GitLab if you configure your own user_filter.
-```sh
+```shell
 ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$base" "$user_filter" sAMAccountName
 ```
@@ -583,7 +583,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$ba
 - Run the following check command to make sure that the LDAP settings are
   correct and GitLab can see your users:
-  ```bash
+  ```shell
   # For Omnibus installations
   sudo gitlab-rake gitlab:ldap:check

doc/administration/auth/oidc.md

@@ -13,13 +13,13 @@ The OpenID Connect will provide you with a client details and secret for you to
    For Omnibus GitLab:
-   ```sh
+   ```shell
    sudo editor /etc/gitlab/gitlab.rb
    ```
    For installations from source:
-   ```sh
+   ```shell
    cd /home/git/gitlab
    sudo -u git -H editor config/gitlab.yml
    ```

doc/administration/auth/okta.md

@@ -46,13 +46,13 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
    **For Omnibus GitLab installations**
-   ```sh
+   ```shell
    sudo editor /etc/gitlab/gitlab.rb
    ```
    **For installations from source**
-   ```sh
+   ```shell
    cd /home/git/gitlab
    sudo -u git -H editor config/gitlab.yml
    ```

doc/administration/file_hooks.md

@@ -94,7 +94,7 @@ The rake task will use a sample data and execute each of file hook. The output
 should be enough to determine if the system sees your file hook and if it was
 executed without errors.
-```bash
+```shell
 # Omnibus installations
 sudo gitlab-rake file_hooks:validate

doc/administration/geo/disaster_recovery/background_verification.md

@@ -27,7 +27,7 @@ the node more time before scheduling a planned failover.
 Run the following commands in a Rails console on the **primary** node:
-```sh
+```shell
 gitlab-rails console
 ```
@@ -95,7 +95,7 @@ The automatic background re-verification is enabled by default, but you can
 disable if you need. Run the following commands in a Rails console on the
 **primary** node:
-```sh
+```shell
 gitlab-rails console
 ```
@@ -120,13 +120,13 @@ to be resynced without the backoff period:
 For repositories:
-```sh
+```shell
 sudo gitlab-rake geo:verification:repository:reset
 ```
 For wikis:
-```sh
+```shell
 sudo gitlab-rake geo:verification:wiki:reset
 ```
@@ -146,25 +146,25 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
    (the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
    is customized, check the directory layout on your server to be sure.
-   ```sh
+   ```shell
    cd /var/opt/gitlab/git-data/repositories
    ```
 1. Run the following command on the **primary** node, redirecting the output to a file:
-   ```sh
+   ```shell
    git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-node-refs
    ```
 1. Run the following command on the **secondary** node, redirecting the output to a file:
-   ```sh
+   ```shell
    git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-node-refs
    ```
 1. Copy the files from the previous steps on the same system, and do a diff between the contents:
-   ```sh
+   ```shell
    diff primary-node-refs secondary-node-refs
    ```

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -21,7 +21,7 @@ To bring the former **primary** node up to date:
 1. SSH into the former **primary** node that has fallen behind.
 1. Make sure all the services are up:
-   ```sh
+   ```shell
    sudo gitlab-ctl start
    ```

doc/administration/geo/disaster_recovery/index.md

@@ -39,13 +39,13 @@ must disable the **primary** node.
 1. SSH into the **primary** node to stop and disable GitLab, if possible:
-   ```sh
+   ```shell
    sudo gitlab-ctl stop
    ```
    Prevent GitLab from starting up again if the server unexpectedly reboots:
-   ```sh
+   ```shell
    sudo systemctl disable gitlab-runsvdir
    ```
@@ -54,7 +54,7 @@ must disable the **primary** node.
    started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
    It may be safest to uninstall the GitLab package completely:
-   ```sh
+   ```shell
    yum remove gitlab-ee
    ```
@@ -63,7 +63,7 @@ must disable the **primary** node.
    or any other distro based on the Upstart init system, you can prevent GitLab
    from starting if the machine reboots by doing the following:
-   ```sh
+   ```shell
    initctl stop gitlab-runsvvdir
    echo 'manual' > /etc/init/gitlab-runsvdir.override
    initctl reload-configuration
@@ -100,7 +100,7 @@ Note the following when promoting a secondary:
 1. SSH in to your **secondary** node and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -117,7 +117,7 @@ Note the following when promoting a secondary:
 1. Promote the **secondary** node to the **primary** node. Execute:
-   ```sh
+   ```shell
    gitlab-ctl promote-to-primary-node
    ```
@@ -135,7 +135,7 @@ do this manually.
 1. SSH in to the database node in the **secondary** and trigger PostgreSQL to
    promote to read-write:
-   ```bash
+   ```shell
    sudo gitlab-pg-ctl promote
    ```
@@ -157,7 +157,7 @@ do this manually.
 1. Promote the **secondary** to **primary**. SSH into a single application
    server and execute:
-   ```bash
+   ```shell
    sudo gitlab-rake geo:set_secondary_as_primary
    ```
@@ -173,7 +173,7 @@ secondary domain, like changing Git remotes and API URLs.
 1. SSH into the **secondary** node and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -192,13 +192,13 @@ secondary domain, like changing Git remotes and API URLs.
 1. Reconfigure the **secondary** node for the change to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
 1. Execute the command below to update the newly promoted **primary** node URL:
-   ```sh
+   ```shell
    gitlab-rake geo:update_primary_node_url
    ```
@@ -223,7 +223,7 @@ Because the **secondary** is already promoted, that data in the tracking databas
 The data can be removed with the following command:
-```sh
+```shell
 sudo rm -rf /var/opt/gitlab/geo-postgresql
 ```
@@ -237,7 +237,7 @@ and after that you also need two extra steps.
 1. SSH into the new **primary** node and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -268,13 +268,13 @@ and after that you also need two extra steps.
 1. Save the file and reconfigure GitLab for the database listen changes and
    the replication slot changes to be applied.
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
    Restart PostgreSQL for its changes to take effect:
-   ```sh
+   ```shell
    gitlab-ctl restart postgresql
    ```
@@ -289,7 +289,7 @@ and after that you also need two extra steps.
    Save the file and reconfigure GitLab:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -65,7 +65,7 @@ supports everything the **primary** node does **before** scheduling a planned fa
 Run the following on both **primary** and **secondary** nodes:
-```sh
+```shell
 gitlab-rake gitlab:check
 gitlab-rake gitlab:geo:check
 ```
@@ -79,7 +79,7 @@ The SSH host keys and `/etc/gitlab/gitlab-secrets.json` files should be
 identical on all nodes. Check this by running the following on all nodes and
 comparing the output:
-```sh
+```shell
 sudo sha256sum /etc/ssh/ssh_host* /etc/gitlab/gitlab-secrets.json
 ```
@@ -136,7 +136,7 @@ access to the **primary** node during the maintenance window.
    For instance, you might run the following commands on the server(s) making up your **primary** node:
-   ```sh
+   ```shell
    sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
    sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
    sudo iptables -A INPUT --destination-port 22 -j REJECT

doc/administration/geo/replication/configuration.md

@@ -30,7 +30,7 @@ they must be manually replicated to the **secondary** node.
 1. SSH into the **primary** node, and execute the command below:
-   ```sh
+   ```shell
    sudo cat /etc/gitlab/gitlab-secrets.json
    ```
@@ -38,20 +38,20 @@ they must be manually replicated to the **secondary** node.
 1. SSH into the **secondary** node and login as the `root` user:
-   ```sh
+   ```shell
    sudo -i
    ```
 1. Make a backup of any existing secrets:
-   ```sh
+   ```shell
    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
    ```
 1. Copy `/etc/gitlab/gitlab-secrets.json` from the **primary** node to the **secondary** node, or
    copy-and-paste the file contents between nodes:
-   ```sh
+   ```shell
    sudo editor /etc/gitlab/gitlab-secrets.json
    # paste the output of the `cat` command you ran on the primary
@@ -60,14 +60,14 @@ they must be manually replicated to the **secondary** node.
 1. Ensure the file permissions are correct:
-   ```sh
+   ```shell
    chown root:root /etc/gitlab/gitlab-secrets.json
    chmod 0600 /etc/gitlab/gitlab-secrets.json
    ```
 1. Reconfigure the **secondary** node for the change to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    gitlab-ctl restart
    ```
@@ -88,13 +88,13 @@ keys must be manually replicated to the **secondary** node.
 1. SSH into the **secondary** node and login as the `root` user:
-   ```sh
+   ```shell
    sudo -i
    ```
 1. Make a backup of any existing SSH host keys:
-   ```sh
+   ```shell
    find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
    ```
@@ -102,14 +102,14 @@ keys must be manually replicated to the **secondary** node.
    If you can access your **primary** node using the **root** user:
-   ```sh
+   ```shell
    # Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
    scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
    ```
    If you only have access through a user with **sudo** privileges:
-   ```sh
+   ```shell
    # Run this from your primary node:
    sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
@@ -120,20 +120,20 @@ keys must be manually replicated to the **secondary** node.
 1. On your **secondary** node, ensure the file permissions are correct:
-   ```sh
+   ```shell
    chown root:root /etc/ssh/ssh_host_*_key*
    chmod 0600 /etc/ssh/ssh_host_*_key*
    ```
 1. To verify key fingerprint matches, execute the following command on both nodes:
-   ```sh
+   ```shell
    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
    ```
    You should get an output similar to this one and they should be identical on both nodes:
-   ```sh
+   ```shell
    1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
    256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
    256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
@@ -142,7 +142,7 @@ keys must be manually replicated to the **secondary** node.
 1. Verify that you have the correct public keys for the existing private keys:
-   ```sh
+   ```shell
    # This will print the fingerprint for private keys:
    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
@@ -155,7 +155,7 @@ keys must be manually replicated to the **secondary** node.
 1. Restart sshd on your **secondary** node:
-   ```sh
+   ```shell
    # Debian or Ubuntu installations
    sudo service ssh reload
@@ -167,7 +167,7 @@ keys must be manually replicated to the **secondary** node.
 1. SSH into your GitLab **secondary** server and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -180,7 +180,7 @@ keys must be manually replicated to the **secondary** node.
 1. Reconfigure the **secondary** node for the change to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
@@ -201,20 +201,20 @@ keys must be manually replicated to the **secondary** node.
 1. Click the **Add node** button to add the **secondary** node.
 1. SSH into your GitLab **secondary** server and restart the services:
-   ```sh
+   ```shell
    gitlab-ctl restart
    ```
    Check if there are any common issue with your Geo setup by running:
-   ```sh
+   ```shell
    gitlab-rake gitlab:geo:check
    ```
 1. SSH into your **primary** server and login as root to verify the
    **secondary** node is reachable or there are any common issue with your Geo setup:
-   ```sh
+   ```shell
    gitlab-rake gitlab:geo:check
    ```

doc/administration/geo/replication/database.md

@@ -49,7 +49,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. SSH into your GitLab **primary** server and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -62,13 +62,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. Reconfigure the **primary** node for the change to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
 1. Execute the command below to define the node as **primary** node:
-   ```sh
+   ```shell
    gitlab-ctl set-geo-primary-node
    ```
@@ -78,7 +78,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    Generate a MD5 hash of the desired password:
-   ```sh
+   ```shell
    gitlab-ctl pg-password-md5 gitlab
    # Enter password: <your_password_here>
    # Confirm password: <your_password_here>
@@ -101,7 +101,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    called `gitlab_replicator`. You must set the password for this user manually.
    You will be prompted to enter a password:
-   ```sh
+   ```shell
    gitlab-ctl set-replication-password
    ```
@@ -134,7 +134,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    To lookup the address of a Geo node, SSH in to the Geo node and execute:
-   ```sh
+   ```shell
    ##
    ## Private address
    ##
@@ -219,13 +219,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. Save the file and reconfigure GitLab for the database listen changes and
    the replication slot changes to be applied:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
    Restart PostgreSQL for its changes to take effect:
-   ```sh
+   ```shell
    gitlab-ctl restart postgresql
    ```
@@ -240,7 +240,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    Save the file and reconfigure GitLab:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
@@ -254,7 +254,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    the **secondary** node needs a copy of the certificate. Make a copy of the PostgreSQL
    `server.crt` file on the **primary** node by running this command:
-   ```sh
+   ```shell
    cat ~gitlab-psql/data/server.crt
    ```
@@ -266,13 +266,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. SSH into your GitLab **secondary** server and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
 1. Stop application server and Sidekiq
-   ```sh
+   ```shell
    gitlab-ctl stop unicorn
    gitlab-ctl stop sidekiq
    ```
@@ -282,7 +282,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. [Check TCP connectivity][rake-maintenance] to the **primary** node's PostgreSQL server:
-   ```sh
+   ```shell
    gitlab-rake gitlab:tcp_check[<primary_node_ip>,5432]
    ```
@@ -295,7 +295,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. Create a file `server.crt` in the **secondary** server, with the content you got on the last step of the **primary** node's setup:
-   ```sh
+   ```shell
    editor server.crt
    ```
@@ -303,7 +303,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    Install the `server.crt` file:
-   ```sh
+   ```shell
    install \
       -D \
       -o gitlab-psql \
@@ -319,7 +319,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. Test that the `gitlab-psql` user can connect to the **primary** node's database
    (the default Omnibus database name is gitlabhq_production):
-   ```sh
+   ```shell
    sudo \
       -u gitlab-psql /opt/gitlab/embedded/bin/psql \
       --list \
@@ -377,13 +377,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 1. Reconfigure GitLab for the changes to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
 1. Restart PostgreSQL for the IP change to take effect and reconfigure again:
-   ```sh
+   ```shell
    gitlab-ctl restart postgresql
    gitlab-ctl reconfigure
    ```
@@ -405,7 +405,7 @@ data before running `pg_basebackup`.
 1. SSH into your GitLab **secondary** server and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -419,7 +419,7 @@ data before running `pg_basebackup`.
    CAUTION: **Warning:** Each Geo **secondary** node must have its own unique replication slot name.
    Using the same slot name between two secondaries will break PostgreSQL replication.
-   ```sh
+   ```shell
    gitlab-ctl replicate-geo-database \
       --slot-name=<secondary_node_name> \
       --host=<primary_node_ip>
@@ -471,7 +471,7 @@ work:
    admin user. If you are using an Omnibus-managed database, log onto the **primary**
    node that is running the PostgreSQL database (the default Omnibus database name is gitlabhq_production):
-   ```sh
+   ```shell
     sudo \
        -u gitlab-psql /opt/gitlab/embedded/bin/psql \
        -h /var/opt/gitlab/postgresql gitlabhq_production
@@ -501,7 +501,7 @@ work:
 1. Save the file and reconfigure GitLab for the changes to be applied:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```

doc/administration/geo/replication/docker_registry.md

@@ -36,7 +36,7 @@ We need to make Docker Registry send notification events to the
 1. SSH into your GitLab **primary** server and login as root:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -70,7 +70,7 @@ We need to make Docker Registry send notification events to the
 1. Reconfigure the **primary** node for the change to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
@@ -90,7 +90,7 @@ generate a short-lived JWT that is pull-only-capable to access the
 1. SSH into the **secondary** node and login as the `root` user:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -105,7 +105,7 @@ generate a short-lived JWT that is pull-only-capable to access the
 1. Reconfigure the **secondary** node for the change to take effect:
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```

doc/administration/geo/replication/external_database.md

@@ -13,13 +13,13 @@ developed and tested. We aim to be compatible with most external
 1. SSH into a GitLab **primary** application server and login as root:
-   ```bash
+   ```shell
    sudo -i
    ```
 1. Execute the command below to define the node as **primary** node:
-   ```bash
+   ```shell
    gitlab-ctl set-geo-primary-node
    ```
@@ -100,7 +100,7 @@ To configure the connection to the external read-replica database and enable Log
 1. SSH into a GitLab **secondary** application server and login as root:
-   ```bash
+   ```shell
    sudo -i
    ```
@@ -147,7 +147,7 @@ the tracking database on port 5432.
 1. SSH into a GitLab **secondary** server and login as root:
-   ```bash
+   ```shell
    sudo -i
    ```
@@ -168,7 +168,7 @@ the tracking database on port 5432.
 1. Run the tracking database migrations:
-   ```bash
+   ```shell
    gitlab-rake geo:db:create
    gitlab-rake geo:db:migrate
    ```
@@ -179,7 +179,7 @@ the tracking database on port 5432.
    Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection
    params to match your environment. Execute it to set up the FDW connection.
-   ```bash
+   ```shell
    #!/bin/bash
    # Secondary Database connection params:
@@ -213,6 +213,6 @@ the tracking database on port 5432.
 1. Save the file and [restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart)
 1. Populate the FDW tables:
-   ```bash
+   ```shell
    gitlab-rake geo:db:refresh_foreign_tables
    ```

doc/administration/geo/replication/high_availability.md

@@ -128,7 +128,7 @@ the **primary** database. Use the following as a guide.
    Note that the username (`gitlab` by default) is incorporated into the hash.
-   ```sh
+   ```shell
    gitlab-ctl pg-password-md5 gitlab
    # Enter password: <your_password_here>
    # Confirm password: <your_password_here>
@@ -187,7 +187,7 @@ Configure the tracking database.
    Note that the username (`gitlab_geo` by default) is incorporated into the
    hash.
-   ```sh
+   ```shell
    gitlab-ctl pg-password-md5 gitlab_geo
    # Enter password: <your_password_here>
    # Confirm password: <your_password_here>

doc/administration/geo/replication/remove_geo_node.md

@@ -10,13 +10,13 @@ Once removed from the Geo admin page, you must stop and uninstall the **secondar
 1. On the **secondary** node, stop GitLab:
-   ```bash
+   ```shell
    sudo gitlab-ctl stop
    ```
 1. On the **secondary** node, uninstall GitLab:
-   ```bash
+   ```shell
    # Stop gitlab and remove its supervision process
    sudo gitlab-ctl uninstall
@@ -31,7 +31,7 @@ Once GitLab has been uninstalled from the **secondary** node, the replication sl
 1. On the **primary** node, start a PostgreSQL console session:
-   ```bash
+   ```shell
    sudo gitlab-psql
    ```

doc/administration/geo/replication/troubleshooting.md

@@ -40,7 +40,7 @@ health check manually to get this information as well as a few more details.
 This rake task can be run on an app node in the **primary** or **secondary**
 Geo nodes:
-```sh
+```shell
 sudo gitlab-rake gitlab:geo:check
 ```
@@ -73,7 +73,7 @@ Checking Geo ... Finished
 Current sync information can be found manually by running this rake task on any
 **secondary** app node:
-```sh
+```shell
 sudo gitlab-rake geo:status
 ```
@@ -127,7 +127,7 @@ This name is used to look up the node with the same **Name** in
 To check if the current machine has a node name that matches a node in the
 database, run the check task:
-```sh
+```shell
 sudo gitlab-rake gitlab:geo:check
 ```
@@ -151,7 +151,7 @@ This machine's Geo node name matches a database record ... no
 When running this rake task, you may see errors if the nodes are not properly configured:
-```sh
+```shell
 sudo gitlab-rake gitlab:geo:check
 ```
@@ -279,7 +279,7 @@ and indicates that your initial dataset is too large to be replicated in the def
 Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
 `--backup-timeout`:
-```sh
+```shell
 sudo gitlab-ctl \
    replicate-geo-database \
    --host=<primary_node_hostname> \
@@ -297,7 +297,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
 1. Start a PostgreSQL console session:
-   ```sh
+   ```shell
    sudo gitlab-psql
    ```
@@ -348,7 +348,7 @@ postgresql['hot_standby_feedback'] = 'on'
 Then reconfigure GitLab:
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
@@ -370,7 +370,7 @@ gitlab_rails['gitlab_shell_git_timeout'] = 10800
 Then reconfigure GitLab:
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
@@ -390,7 +390,7 @@ to start again from scratch, there are a few steps that can help you:
    You need to send a **SIGTSTP** kill signal for the first phase and them a **SIGTERM**
    when all jobs have finished. Otherwise just use the `gitlab-ctl stop` commands.
-   ```sh
+   ```shell
    gitlab-ctl status sidekiq
    # run: sidekiq: (pid 10180) <- this is the PID you will use
    kill -TSTP 10180 # change to the correct PID
@@ -401,13 +401,13 @@ to start again from scratch, there are a few steps that can help you:
    You can watch Sidekiq logs to know when Sidekiq jobs processing have finished:
-   ```sh
+   ```shell
    gitlab-ctl tail sidekiq
    ```
 1. Rename repository storage folders and create new ones. If you are not concerned about possible orphaned directories and files, then you can simply skip this step.
-   ```sh
+   ```shell
    mv /var/opt/gitlab/git-data/repositories /var/opt/gitlab/git-data/repositories.old
    mkdir -p /var/opt/gitlab/git-data/repositories
    chown git:git /var/opt/gitlab/git-data/repositories
@@ -432,7 +432,7 @@ to start again from scratch, there are a few steps that can help you:
    To rename all of them:
-   ```sh
+   ```shell
    gitlab-ctl stop
    mv /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared.old
@@ -447,13 +447,13 @@ to start again from scratch, there are a few steps that can help you:
    Reconfigure in order to recreate the folders and make sure permissions and ownership
    are correctly
-   ```sh
+   ```shell
    gitlab-ctl reconfigure
    ```
 1. Reset the Tracking Database
-   ```sh
+   ```shell
    gitlab-rake geo:db:drop
    gitlab-ctl reconfigure
    gitlab-rake geo:db:setup
@@ -461,7 +461,7 @@ to start again from scratch, there are a few steps that can help you:
 1. Restart previously stopped services
-   ```sh
+   ```shell
    gitlab-ctl start
    ```
@@ -537,7 +537,7 @@ To check the configuration:
 1. SSH into an app node in the **secondary**:
-   ```sh
+   ```shell
    sudo -i
    ```
@@ -552,14 +552,14 @@ To check the configuration:
    If the tracking database is running on the same node:
-   ```sh
+   ```shell
    gitlab-geo-psql
    ```
    Or, if the tracking database is running on a different node, you must specify
    the user and host when entering the database console:
-   ```sh
+   ```shell
    gitlab-geo-psql -U gitlab_geo -h <IP of tracking database>
    ```
@@ -646,7 +646,7 @@ To check the configuration:
    Make sure the password is correct. You can test that logins work by running `psql`:
-   ```sh
+   ```shell
    # Connect to the tracking database as the `gitlab_geo` user
    sudo \
       -u git /opt/gitlab/embedded/bin/psql \
@@ -685,7 +685,7 @@ reload of the FDW schema. To manually reload the FDW schema:
 1. On the node running the Geo tracking database, enter the PostgreSQL console via
    the `gitlab_geo` user:
-   ```sh
+   ```shell
    sudo \
       -u git /opt/gitlab/embedded/bin/psql \
       -h /var/opt/gitlab/geo-postgresql \
@@ -729,7 +729,7 @@ Geo database has an outdated FDW remote schema. It contains 229 of 236 expected
 To resolve this, run the following command:
-```sh
+```shell
 sudo gitlab-rake geo:db:refresh_foreign_tables
 ```