Standardize codeblock fences (sh)

Find and replace sh with shell

doc/administration/audit_events.md

@@ -144,7 +144,7 @@ the steps bellow.
 
 1. Enter the Rails console:
 
-   ```sh
+   ```shell
    sudo gitlab-rails console
    ```
 

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.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
 ```
 

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/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
    ```
 
@@ -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/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/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
 ```
 

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
    ```
 

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,26 +331,26 @@ 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
       ```
 
@@ -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
    ```
 

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
 ```
 

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",

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
 ```
 

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 '*'
       ```
 

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
 ```
 

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
    ```

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
 ```
 

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 ;
    ```
 

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
    ```
 

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
 ```
 

doc/administration/job_artifacts.md

@@ -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
    ```

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
 

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

doc/administration/monitoring/performance/grafana_configuration.md

@@ -133,7 +133,7 @@ After upgrading, the Grafana dashboard will be disabled and the location of your
 
 To prevent the data from being relocated, you can run the following command prior to upgrading:
 
-```sh
+```shell
 echo "0" > /var/opt/gitlab/grafana/CVE_reset_status
 ```
 

doc/administration/operations/extra_sidekiq_processes.md

@@ -55,7 +55,7 @@ To start extra Sidekiq processes, you must enable `sidekiq-cluster`:
 
 1. Save the file and reconfigure GitLab for the changes to take effect:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 
@@ -78,7 +78,7 @@ you list:
 
 1. Save the file and reconfigure GitLab for the changes to take effect:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 
@@ -113,7 +113,7 @@ use all of its resources to perform those operations. To set up a separate
 
 1. Save the file and reconfigure GitLab for the changes to take effect:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 
@@ -145,7 +145,7 @@ details.
 
 1. Save the file and reconfigure GitLab for the changes to take effect:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 
@@ -162,7 +162,7 @@ This will set the concurrency (number of threads) for the Sidekiq process.
 
 1. Save the file and reconfigure GitLab for the changes to take effect:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 

doc/administration/operations/filesystem_benchmarking.md

@@ -25,7 +25,7 @@ To install:
 
 Then run the following:
 
-```sh
+```shell
 fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/path/to/git-data/testfile --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
 ```
 
@@ -78,32 +78,32 @@ executed, and then read the same 1,000 files.
    [repository storage path](../repository_storage_paths.md).
 1. Create a temporary directory for the test so it's easy to remove the files later:
 
-   ```sh
+   ```shell
    mkdir test; cd test
    ```
 
 1. Run the command:
 
-   ```sh
+   ```shell
    time for i in {0..1000}; do echo 'test' > "test${i}.txt"; done
    ```
 
 1. To benchmark read performance, run the command:
 
-   ```sh
+   ```shell
    time for i in {0..1000}; do cat "test${i}.txt" > /dev/null; done
    ```
 
 1. Remove the test files:
 
-  ```sh
+  ```shell
   cd ../; rm -rf test
   ```
 
 The output of the `time for ...` commands will look similar to the following. The
 important metric is the `real` time.
 
-```sh
+```shell
 $ time for i in {0..1000}; do echo 'test' > "test${i}.txt"; done
 
 real    0m0.116s

doc/administration/packages/index.md

@@ -166,7 +166,7 @@ The processing will be done in a background worker and requires **no downtime**.
 
 For Omnibus GitLab:
 
-```sh
+```shell
 sudo gitlab-rake "gitlab:packages:migrate"
 ```
 

doc/administration/raketasks/uploads/sanitize.md

@@ -7,7 +7,7 @@ You need `exiftool` installed on your system. If you installed GitLab:
 - Using the Omnibus package, you're all set.
 - From source, make sure `exiftool` is installed:
 
-  ```sh
+  ```shell
   # Debian/Ubuntu
   sudo apt-get install libimage-exiftool-perl
 

doc/administration/reply_by_email_postfix_setup.md

@@ -14,7 +14,7 @@ The instructions make the assumption that you will be using the email address `i
 
 1. Install the `postfix` package if it is not installed already:
 
-   ```sh
+   ```shell
    sudo apt-get install postfix
    ```
 
@@ -22,7 +22,7 @@ The instructions make the assumption that you will be using the email address `i
 
 1. Install the `mailutils` package.
 
-   ```sh
+   ```shell
    sudo apt-get install mailutils
    ```
 
@@ -30,13 +30,13 @@ The instructions make the assumption that you will be using the email address `i
 
 1. Create a user for incoming email.
 
-   ```sh
+   ```shell
    sudo useradd -m -s /bin/bash incoming
    ```
 
 1. Set a password for this user.
 
-   ```sh
+   ```shell
    sudo passwd incoming
    ```
 
@@ -46,13 +46,13 @@ The instructions make the assumption that you will be using the email address `i
 
 1. Connect to the local SMTP server:
 
-   ```sh
+   ```shell
    telnet localhost 25
    ```
 
    You should see a prompt like this:
 
-   ```sh
+   ```shell
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
@@ -61,13 +61,13 @@ The instructions make the assumption that you will be using the email address `i
 
    If you get a `Connection refused` error instead, verify that `postfix` is running:
 
-   ```sh
+   ```shell
    sudo postfix status
    ```
 
    If it is not, start it:
 
-   ```sh
+   ```shell
    sudo postfix start
    ```
 
@@ -94,7 +94,7 @@ The instructions make the assumption that you will be using the email address `i
 
 1. Check if the `incoming` user received the email:
 
-   ```sh
+   ```shell
    su - incoming
    mail
    ```
@@ -108,13 +108,13 @@ The instructions make the assumption that you will be using the email address `i
 
    Quit the mail app:
 
-   ```sh
+   ```shell
    q
    ```
 
 1. Log out of the `incoming` account and go back to being `root`:
 
-   ```sh
+   ```shell
    logout
    ```
 
@@ -124,13 +124,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
 1. Configure Postfix to use Maildir-style mailboxes:
 
-   ```sh
+   ```shell
    sudo postconf -e "home_mailbox = Maildir/"
    ```
 
 1. Restart Postfix:
 
-   ```sh
+   ```shell
    sudo /etc/init.d/postfix restart
    ```
 
@@ -139,7 +139,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
    1. Follow steps 1 and 2 of _[Test the out-of-the-box setup](#test-the-out-of-the-box-setup)_.
    1. Check if the `incoming` user received the email:
 
-      ```sh
+      ```shell
       su - incoming
       MAIL=/home/incoming/Maildir
       mail
@@ -154,7 +154,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
       Quit the mail app:
 
-      ```sh
+      ```shell
       q
       ```
 
@@ -166,7 +166,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
 1. Log out of the `incoming` account and go back to being `root`:
 
-   ```sh
+   ```shell
    logout
    ```
 
@@ -174,25 +174,25 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
 1. Install the `courier-imap` package:
 
-   ```sh
+   ```shell
    sudo apt-get install courier-imap
    ```
 
    And start `imapd`:
 
-   ```sh
+   ```shell
    imapd start
    ```
 
 1. The courier-authdaemon isn't started after installation. Without it, imap authentication will fail:
 
-   ```sh
+   ```shell
    sudo service courier-authdaemon start
    ```
 
    You can also configure courier-authdaemon to start on boot:
 
-   ```sh
+   ```shell
    sudo systemctl enable courier-authdaemon
    ```
 
@@ -200,7 +200,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
 1. Let Postfix know about the domains that it should consider local:
 
-   ```sh
+   ```shell
    sudo postconf -e "mydestination = gitlab.example.com, localhost.localdomain, localhost"
    ```
 
@@ -208,25 +208,25 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    We'll assume `192.168.1.0/24` is your local LAN. You can safely skip this step if you don't have other machines in the same local network.
 
-   ```sh
+   ```shell
    sudo postconf -e "mynetworks = 127.0.0.0/8, 192.168.1.0/24"
    ```
 
 1. Configure Postfix to receive mail on all interfaces, which includes the internet:
 
-   ```sh
+   ```shell
    sudo postconf -e "inet_interfaces = all"
    ```
 
 1. Configure Postfix to use the `+` delimiter for sub-addressing:
 
-   ```sh
+   ```shell
    sudo postconf -e "recipient_delimiter = +"
    ```
 
 1. Restart Postfix:
 
-   ```sh
+   ```shell
    sudo service postfix restart
    ```
 
@@ -236,13 +236,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    1. Connect to the SMTP server:
 
-      ```sh
+      ```shell
       telnet gitlab.example.com 25
       ```
 
       You should see a prompt like this:
 
-      ```sh
+      ```shell
       Trying 123.123.123.123...
       Connected to gitlab.example.com.
       Escape character is '^]'.
@@ -269,7 +269,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    1. Check if the `incoming` user received the email:
 
-      ```sh
+      ```shell
       su - incoming
       MAIL=/home/incoming/Maildir
       mail
@@ -284,13 +284,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
       Quit the mail app:
 
-      ```sh
+      ```shell
       q
       ```
 
    1. Log out of the `incoming` account and go back to being `root`:
 
-      ```sh
+      ```shell
       logout
       ```
 
@@ -298,13 +298,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    1. Connect to the IMAP server:
 
-      ```sh
+      ```shell
       telnet gitlab.example.com 143
       ```
 
       You should see a prompt like this:
 
-      ```sh
+      ```shell
       Trying 123.123.123.123...
       Connected to mail.example.gitlab.com.
       Escape character is '^]'.
@@ -327,7 +327,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    1. Disconnect from the IMAP server:
 
-      ```sh
+      ```shell
       a logout
       ```
 

doc/administration/timezone.md

@@ -31,7 +31,7 @@ gitlab_rails['time_zone'] = 'America/New_York'
 
 After adding the configuration parameter, reconfigure and restart your GitLab instance:
 
-```sh
+```shell
 gitlab-ctl reconfigure
 gitlab-ctl restart
 ```

doc/administration/troubleshooting/debug.md

@@ -10,13 +10,13 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
 
 1. Run a Rails console:
 
-   ```sh
+   ```shell
    sudo gitlab-rails console production
    ```
 
    or for source installs:
 
-   ```sh
+   ```shell
    bundle exec rails console production
    ```
 

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -995,13 +995,13 @@ See <https://github.com/mperham/sidekiq/wiki/Signals#ttin>.
 
 ### Connect to Redis (omnibus)
 
-```sh
+```shell
 /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
 ```
 
 ### Connect to Redis (HA)
 
-```sh
+```shell
 /opt/gitlab/embedded/bin/redis-cli -h <host ip> -a <password>
 ```
 

doc/administration/troubleshooting/linux_cheat_sheet.md

@@ -200,7 +200,7 @@ can also sort based on total time, # of syscalls made, PID #, and # of child pro
 using the `-S` or `--sort` flag. The number of results defaults to 25 processes, but
 can be changed using the `-c`/`--count` option.  See `--help` for full details.
 
-```sh
+```shell
 $ ./strace-parser strace.txt
 
 Top 25 PIDs
@@ -218,7 +218,7 @@ Based on the summary, you can then view the details of syscalls made by one or m
 procsses using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for
 a sorted list. `--stats` takes the same sorting and count options as summary.
 
-```sh
+```shell
 $ ./strace-parse strace.text -p 6423
 
 PID 6423

doc/administration/troubleshooting/test_environments.md

@@ -37,7 +37,7 @@ you change a few things:
 
 For example, when the `docker-machine` host we want to use is `do-docker`:
 
-```sh
+```shell
 docker run --detach --name gitlab \
 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://$(docker-machine ip do-docker)'; gitlab_rails['gitlab_shell_ssh_port'] = 2222;" \
 --hostname $(docker-machine ip do-docker) \
@@ -52,7 +52,7 @@ gitlab/gitlab-ee:11.5.3-ee.0
 We can use the [`test-saml-idp` Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
 to do the work for us:
 
-```sh
+```shell
 docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \
 -e SIMPLESAMLPHP_SP_ENTITY_ID=<GITLAB_IP_OR_DOMAIN> \
 -e SIMPLESAMLPHP_SP_ASSERTION_CONSUMER_SERVICE=<GITLAB_IP_OR_DOMAIN>/users/auth/saml/callback \
@@ -93,7 +93,7 @@ See [the GDK SAML documentation](https://gitlab.com/gitlab-org/gitlab-developmen
 
 ### Elasticsearch
 
-```sh
+```shell
 docker run -d --name elasticsearch \
 -p 9200:9200 -p 9300:9300 \
 -e "discovery.type=single-node" \
@@ -110,7 +110,7 @@ on running PlantUML in Docker.
 
 ### Jira
 
-```sh
+```shell
 docker run -d -p 8081:8080 cptactionhank/atlassian-jira:latest
 ```
 
@@ -119,7 +119,7 @@ Jira license.
 
 ### Grafana
 
-```sh
+```shell
 docker run -d --name grafana -e "GF_SECURITY_ADMIN_PASSWORD=gitlab" -p 3000:3000 grafana/grafana
 ```
 

doc/api/applications.md

@@ -31,7 +31,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --data "name=MyApplication&redirect_uri=http://redirect.uri&scopes=" https://gitlab.example.com/api/v4/applications
 ```
 
@@ -58,7 +58,7 @@ GET /applications
 
 Example request:
 
-```sh
+```shell
 curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/applications
 ```
 
@@ -97,6 +97,6 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/applications/:id
 ```

doc/api/avatar.md

@@ -28,7 +28,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl https://gitlab.example.com/api/v4/avatar?email=admin@example.com&size=32
 ```
 

doc/api/award_emoji.md

@@ -35,7 +35,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji
 ```
 
@@ -98,7 +98,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji/1
 ```
 
@@ -141,7 +141,7 @@ Parameters:
 | `issue_iid`/`merge_request_iid`/`snippet_id` | integer        | yes      | ID (`iid` for merge requests/issues, `id` for snippets) of an awardable.     |
 | `name`         | string         | yes      | Name of the emoji without colons.                                            |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji?name=blowfish
 ```
 
@@ -187,7 +187,7 @@ Parameters:
 | `issue_iid`/`merge_request_iid`/`snippet_id` | integer        | yes      | ID (`iid` for merge requests/issues, `id` for snippets) of an awardable.     |
 | `award_id`     | integer        | yes      | ID of an award emoji.                                                        |
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji/344
 ```
 
@@ -218,7 +218,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/notes/1/award_emoji
 ```
 
@@ -264,7 +264,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/notes/1/award_emoji/2
 ```
 
@@ -308,7 +308,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/notes/1/award_emoji?name=rocket
 ```
 
@@ -355,6 +355,6 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji/345
 ```

doc/api/branches.md

@@ -25,7 +25,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/repository/branches
 ```
 
@@ -81,7 +81,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/repository/branches/master
 ```
 
@@ -142,7 +142,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/repository/branches?branch=newbranch&ref=master
 ```
 
@@ -195,7 +195,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/repository/branches/newbranch
 ```
 
@@ -218,6 +218,6 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/repository/merged_branches
 ```

doc/api/broadcast_messages.md

@@ -19,7 +19,7 @@ GET /broadcast_messages
 
 Example request:
 
-```sh
+```shell
 curl https://gitlab.example.com/api/v4/broadcast_messages
 ```
 
@@ -56,7 +56,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl https://gitlab.example.com/api/v4/broadcast_messages/1
 ```
 
@@ -95,7 +95,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --data "message=Deploy in progress&color=#cecece" --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/broadcast_messages
 ```
 
@@ -135,7 +135,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request PUT --data "message=Update message&color=#000" --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/broadcast_messages/1
 ```
 
@@ -158,7 +158,7 @@ Example response:
 
 Delete a broadcast message.
 
-```sh
+```shell
 DELETE /broadcast_messages/:id
 ```
 
@@ -170,6 +170,6 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/broadcast_messages/1
 ```

doc/api/graphql/getting_started.md

@@ -21,7 +21,7 @@ to use as a bearer token.
 
 Example:
 
-```sh
+```shell
 GRAPHQL_TOKEN=<your-token>
 curl 'https://gitlab.com/api/graphql' --header "Authorization: Bearer $GRAPHQL_TOKEN" --header "Content-Type: application/json" --request POST --data "{\"query\": \"query {currentUser {name}}\"}"
 ```

doc/api/issues.md

@@ -1427,7 +1427,7 @@ GET /projects/:id/issues/:issue_id/related_merge_requests
 | `id`        | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user  |
 | `issue_iid` | integer | yes      | The internal ID of a project's issue |
 
-```sh
+```shell
 curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/issues/11/related_merge_requests
 ```
 

doc/api/jobs.md

@@ -13,7 +13,7 @@ GET /projects/:id/jobs
 | `id`      | integer/string                 | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user.                                                                                               |
 | `scope`   | string **or** array of strings | no       | Scope of jobs to show. Either one of or an array of the following: `created`, `pending`, `running`, `failed`, `success`, `canceled`, `skipped`, or `manual`. All jobs are returned if `scope` is not provided. |
 
-```sh
+```shell
 curl --globoff --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/projects/1/jobs?scope[]=pending&scope[]=running'
 ```
 
@@ -148,7 +148,7 @@ GET /projects/:id/pipelines/:pipeline_id/jobs
 | `pipeline_id` | integer                        | yes      | ID of a pipeline.                                                                                                                                                                                          |
 | `scope`       | string **or** array of strings | no       | Scope of jobs to show. Either one of or an array of the following: `created`, `pending`, `running`, `failed`, `success`, `canceled`, `skipped`, or `manual`. All jobs are returned if `scope` is not provided. |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/projects/1/pipelines/6/jobs?scope[]=pending&scope[]=running'
 ```
 
@@ -282,7 +282,7 @@ GET /projects/:id/jobs/:job_id
 | `id`      | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `job_id`  | integer        | yes      | ID of a job.                                                                                                 |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/8"
 ```
 
@@ -363,7 +363,7 @@ GET /projects/:id/jobs/:job_id/artifacts
 
 Example request using the `PRIVATE-TOKEN` header:
 
-```sh
+```shell
 curl --output artifacts.zip --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/42/artifacts"
 ```
 
@@ -429,7 +429,7 @@ Parameters
 
 Example request using the `PRIVATE-TOKEN` header:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test"
 ```
 
@@ -490,7 +490,7 @@ Parameters
 
 Example request:
 
-```sh
+```shell
 curl --location --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/5/artifacts/some/release/file.pdf"
 ```
 
@@ -525,7 +525,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --location --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/raw/some/release/file.pdf?job=pdf"
 ```
 
@@ -550,7 +550,7 @@ GET /projects/:id/jobs/:job_id/trace
 | id        | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | job_id    | integer        | yes      | ID of a job.                                                                                                 |
 
-```sh
+```shell
 curl --location --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/8/trace"
 ```
 
@@ -574,7 +574,7 @@ POST /projects/:id/jobs/:job_id/cancel
 | `id`      | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `job_id`  | integer        | yes      | ID of a job.                                                                                                 |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/cancel"
 ```
 
@@ -623,7 +623,7 @@ POST /projects/:id/jobs/:job_id/retry
 | `id`      | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `job_id`  | integer        | yes      | ID of a job.                                                                                                 |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/retry"
 ```
 
@@ -676,7 +676,7 @@ Parameters
 
 Example of request
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/erase"
 ```
 
@@ -730,7 +730,7 @@ Parameters
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/artifacts/keep"
 ```
 
@@ -784,7 +784,7 @@ DELETE /projects/:id/jobs/:job_id/artifacts
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/artifacts"
 ```
 
@@ -806,7 +806,7 @@ POST /projects/:id/jobs/:job_id/play
 | `id`      | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `job_id`  | integer        | yes      | ID of a job.                                                                                                 |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/play"
 ```
 

doc/api/keys.md

@@ -14,7 +14,7 @@ GET /keys/:id
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/keys/1
 ```
 
@@ -72,7 +72,7 @@ GET /keys
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/keys?fingerprint=ba:81:59:68:d7:6c:cd:02:02:bf:6a:9b:55:4e:af:d1'
 ```
 
@@ -80,7 +80,7 @@ If using sha256 fingerprint API calls, make sure that the fingerprint is URL-enc
 
 For example, `/` is represented by `%2F` and `:` is represented by`%3A`:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/keys?fingerprint=SHA256%3AnUhzNyftwADy8AH3wFY31tAKs7HufskYTte2aXo%2FlCg
 ```
 
@@ -138,7 +138,7 @@ fingerprint you get additional information about the projects using that key.
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/keys?fingerprint=SHA256%3AnUhzNyftwADy8AH3wFY31tAKs7HufskYTte2aXo%2FlCg
 ```
 

doc/api/oauth2.md

@@ -175,7 +175,7 @@ the following parameters:
 
 Example cURL request:
 
-```sh
+```shell
 echo 'grant_type=password&username=<your_username>&password=<your_password>' > auth.txt
 curl --data "@auth.txt" --request POST https://gitlab.example.com/oauth/token
 ```

doc/api/pipeline_schedules.md

@@ -15,7 +15,7 @@ GET /projects/:id/pipeline_schedules
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `scope`   | string  | no       | The scope of pipeline schedules, one of: `active`, `inactive` |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules"
 ```
 
@@ -56,7 +56,7 @@ GET /projects/:id/pipeline_schedules/:pipeline_schedule_id
 | `id`         | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user      |
 | `pipeline_schedule_id` | integer | yes      | The pipeline schedule id           |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13"
 ```
 
@@ -112,7 +112,7 @@ POST /projects/:id/pipeline_schedules
 | `cron_timezone` | string  | no      | The timezone supported by `ActiveSupport::TimeZone` (e.g. `Pacific Time (US & Canada)`) (default: `'UTC'`)     |
 | `active` | boolean  | no      | The activation of pipeline schedule. If false is set, the pipeline schedule will deactivated initially (default: `true`) |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" --form description="Build packages" --form ref="master" --form cron="0 1 * * 5" --form cron_timezone="UTC" --form active="true" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules"
 ```
 
@@ -157,7 +157,7 @@ PUT /projects/:id/pipeline_schedules/:pipeline_schedule_id
 | `cron_timezone` | string  | no      | The timezone supported by `ActiveSupport::TimeZone` (e.g. `Pacific Time (US & Canada)`) or `TZInfo::Timezone` (e.g. `America/Los_Angeles`)      |
 | `active` | boolean  | no      | The activation of pipeline schedule. If false is set, the pipeline schedule will deactivated initially. |
 
-```sh
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" --form cron="0 2 * * *" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13"
 ```
 
@@ -202,7 +202,7 @@ POST /projects/:id/pipeline_schedules/:pipeline_schedule_id/take_ownership
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user      |
 | `pipeline_schedule_id`  | integer | yes      | The pipeline schedule id           |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: hf2CvZXB9w8Uc5pZKpSB" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13/take_ownership"
 ```
 
@@ -247,7 +247,7 @@ DELETE /projects/:id/pipeline_schedules/:pipeline_schedule_id
 | `id`           | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user      |
 | `pipeline_schedule_id`   | integer | yes      | The pipeline schedule id           |
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13"
 ```
 
@@ -299,7 +299,7 @@ POST /projects/:id/pipeline_schedules/:pipeline_schedule_id/variables
 | `value`                | string         | yes      | The `value` of a variable |
 | `variable_type`        | string         | no       | The type of a variable. Available types are: `env_var` (default) and `file` |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" --form "key=NEW_VARIABLE" --form "value=new value" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13/variables"
 ```
 
@@ -327,7 +327,7 @@ PUT /projects/:id/pipeline_schedules/:pipeline_schedule_id/variables/:key
 | `value`                | string         | yes      | The `value` of a variable |
 | `variable_type`        | string         | no       | The type of a variable. Available types are: `env_var` (default) and `file` |
 
-```sh
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" --form "value=updated value" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13/variables/NEW_VARIABLE"
 ```
 
@@ -353,7 +353,7 @@ DELETE /projects/:id/pipeline_schedules/:pipeline_schedule_id/variables/:key
 | `pipeline_schedule_id` | integer        | yes      | The pipeline schedule id |
 | `key`                  | string         | yes      | The `key` of a variable |
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules/13/variables/NEW_VARIABLE"
 ```
 

doc/api/project_import_export.md

@@ -28,7 +28,7 @@ POST /projects/:id/export
 | `upload[url]`      | string | yes      | The URL to upload the project |
 | `upload[http_method]`      | string | no      | The HTTP method to upload the exported project. Only `PUT` and `POST` methods allowed. Default is `PUT` |
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/export \
     --data "upload[http_method]=PUT" \
     --data-urlencode "upload[url]=https://example-bucket.s3.eu-west-3.amazonaws.com/backup?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIMBJHN2O62W8IELQ%2F20180312%2Feu-west-3%2Fs3%2Faws4_request&X-Amz-Date=20180312T110328Z&X-Amz-Expires=900&X-Amz-SignedHeaders=host&X-Amz-Signature=8413facb20ff33a49a147a0b4abcff4c8487cc33ee1f7e450c46e8f695569dbd"
@@ -52,7 +52,7 @@ GET /projects/:id/export
 | --------- | -------------- | -------- | ---------------------------------------- |
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/export
 ```
 
@@ -93,11 +93,11 @@ GET /projects/:id/export/download
 | --------- | -------------- | -------- | ---------------------------------------- |
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" --remote-header-name --remote-name https://gitlab.example.com/api/v4/projects/5/export/download
 ```
 
-```sh
+```shell
 ls *export.tar.gz
 2017-12-05_22-11-148_namespace_project_export.tar.gz
 ```
@@ -124,7 +124,7 @@ cURL to post data using the header `Content-Type: multipart/form-data`.
 The `file=` parameter must point to a file on your file system and be preceded
 by `@`. For example:
 
-```sh
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "path=api-project" --form "file=@/path/to/file" https://gitlab.example.com/api/v4/projects/import
 ```
 
@@ -174,7 +174,7 @@ GET /projects/:id/import
 | --------- | -------------- | -------- | ---------------------------------------- |
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/import
 ```
 

doc/api/releases/index.md

@@ -19,7 +19,7 @@ GET /projects/:id/releases
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases"
 ```
 
@@ -202,7 +202,7 @@ GET /projects/:id/releases/:tag_name
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1"
 ```
 
@@ -322,7 +322,7 @@ POST /projects/:id/releases
 
 Example request:
 
-```sh
+```shell
 curl --header 'Content-Type: application/json' --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" \
      --data '{ "name": "New release", "tag_name": "v0.3", "description": "Super nice release", "milestones": ["v1.0", "v1.0-rc"], "assets": { "links": [{ "name": "hoge", "url": "https://google.com" }] } }' \
      --request POST https://gitlab.example.com/api/v4/projects/24/releases
@@ -445,7 +445,7 @@ PUT /projects/:id/releases/:tag_name
 
 Example request:
 
-```sh
+```shell
 curl --header 'Content-Type: application/json' --request PUT --data '{"name": "new name", "milestones": ["v1.2"]}' --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1"
 ```
 
@@ -544,7 +544,7 @@ DELETE /projects/:id/releases/:tag_name
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1"
 ```
 

doc/api/releases/links.md

@@ -20,7 +20,7 @@ GET /projects/:id/releases/:tag_name/assets/links
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1/assets/links"
 ```
 
@@ -59,7 +59,7 @@ GET /projects/:id/releases/:tag_name/assets/links/:link_id
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1/assets/links/1"
 ```
 
@@ -91,7 +91,7 @@ POST /projects/:id/releases/:tag_name/assets/links
 
 Example request:
 
-```sh
+```shell
 curl --request POST \
      --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" \
      --data name="awesome-v0.2.dmg" \
@@ -131,7 +131,7 @@ You have to specify at least one of `name` or `url`
 
 Example request:
 
-```sh
+```shell
 curl --request PUT --data name="new name" --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1/assets/links/1"
 ```
 
@@ -162,7 +162,7 @@ DELETE /projects/:id/releases/:tag_name/assets/links/:link_id
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1/assets/links/1"
 ```
 

doc/api/repositories.md

@@ -121,7 +121,7 @@ Parameters:
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
 - `sha` (optional) - The commit SHA to download. A tag, branch reference, or SHA can be used. This defaults to the tip of the default branch if not specified. For example:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.com/api/v4/projects/<project_id>/repository/archive?sha=<commit_sha>
 ```
 

doc/api/repository_submodules.md

@@ -21,7 +21,7 @@ PUT /projects/:id/repository/submodules/:submodule
 | `commit_sha` | string | yes | Full commit SHA to update the submodule to |
 | `commit_message` | string | no | Commit message. If no message is provided, a default one will be set |
 
-```sh
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/repository/submodules/lib%2Fmodules%2Fexample"
 --data "branch=master&commit_sha=3ddec28ea23acc5caa5d8331a6ecb2a65fc03e88&commit_message=Update submodule reference"
 ```

doc/api/scim.md

@@ -31,7 +31,7 @@ Pagination follows the [SCIM spec](https://tools.ietf.org/html/rfc7644#section-3
 
 Example request:
 
-```sh
+```shell
 curl 'https://example.gitlab.com/api/scim/v2/groups/test_group/Users?filter=id%20eq%20"0b1d561c-21ff-4092-beab-8154b17f82f2"' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
@@ -82,7 +82,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl 'https://example.gitlab.com/api/scim/v2/groups/test_group/Users/f0b1d561c-21ff-4092-beab-8154b17f82f2' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
@@ -126,7 +126,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --verbose --request POST 'https://example.gitlab.com/api/scim/v2/groups/test_group/Users' --data '{"externalId":"test_uid","active":null,"userName":"username","emails":[{"primary":true,"type":"work","value":"name@example.com"}],"name":{"formatted":"Test User","familyName":"User","givenName":"Test"},"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"meta":{"resourceType":"User"}}' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
@@ -180,7 +180,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --verbose --request PATCH 'https://example.gitlab.com/api/scim/v2/groups/test_group/Users/f0b1d561c-21ff-4092-beab-8154b17f82f2' --data '{ "Operations": [{"op":"Add","path":"name.formatted","value":"New Name"}] }' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
@@ -203,7 +203,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --verbose --request DELETE 'https://example.gitlab.com/api/scim/v2/groups/test_group/Users/f0b1d561c-21ff-4092-beab-8154b17f82f2' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 

doc/api/snippets.md

@@ -27,7 +27,7 @@ GET /snippets
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/snippets
 ```
 
@@ -94,7 +94,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/snippets/1
 ```
 
@@ -138,7 +138,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/snippets/1/raw
 ```
 
@@ -171,7 +171,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request POST \
      --data '{"title": "This is a snippet", "content": "Hello world", "description": "Hello World snippet", "file_name": "test.txt", "visibility": "internal" }' \
      --header 'Content-Type: application/json' \
@@ -227,7 +227,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request PUT \
      --data '{"title": "foo", "content": "bar"}' \
      --header 'Content-Type: application/json' \
@@ -275,7 +275,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/snippets/1"
 ```
 
@@ -303,7 +303,7 @@ Parameters:
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/snippets/public?per_page=2&page=1
 ```
 
@@ -366,7 +366,7 @@ GET /snippets/:id/user_agent_detail
 
 Example request:
 
-```sh
+```shell
 curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/snippets/1/user_agent_detail
 ```
 

doc/ci/docker/using_docker_build.md

@@ -384,7 +384,7 @@ aware of the following implications:
   work as expected since volume mounting is done in the context of the host
   machine, not the build container. For example:
 
-   ```sh
+   ```shell
    docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests
    ```
 
@@ -458,13 +458,13 @@ which can be avoided if a different driver is used, for example `overlay2`.
 1. Make sure a recent kernel is used, preferably `>= 4.2`.
 1. Check whether the `overlay` module is loaded:
 
-   ```sh
+   ```shell
    sudo lsmod | grep overlay
    ```
 
    If you see no result, then it isn't loaded. To load it use:
 
-   ```sh
+   ```shell
    sudo modprobe overlay
    ```
 
@@ -542,7 +542,7 @@ For all projects, mostly suitable for public ones:
   your Docker images and has read/write access to the Registry. This is ephemeral,
   so it's only valid for one job. You can use the following example as-is:
 
-  ```sh
+  ```shell
   docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
   ```
 
@@ -557,7 +557,7 @@ For private and internal projects:
 
   Replace the `<username>` and `<access_token>` in the following example:
 
-  ```sh
+  ```shell
   docker login -u <username> -p <access_token> $CI_REGISTRY
   ```
 
@@ -567,7 +567,7 @@ For private and internal projects:
   Once created, you can use the special environment variables, and GitLab CI/CD
   will fill them in for you. You can use the following example as-is:
 
-  ```sh
+  ```shell
   docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
   ```
 
@@ -602,7 +602,7 @@ assuming you have it configured with [TLS enabled](#tls-enabled):
 If you forget to set the service alias, the `docker:19.03.1` image won't find the
 `dind` service, and an error like the following is thrown:
 
-```sh
+```shell
 $ docker info
 error during connect: Get http://docker:2376/v1.39/info: dial tcp: lookup docker on 192.168.0.1:53: no such host
 ```

doc/ci/docker/using_docker_images.md

@@ -805,7 +805,7 @@ is specific to your project.
 
 Then create some service containers:
 
-```sh
+```shell
 docker run -d --name service-mysql mysql:latest
 docker run -d --name service-postgres postgres:latest
 ```
@@ -817,7 +817,7 @@ respectively. They will both run in the background (`-d`).
 Finally, create a build container by executing the `build_script` file we
 created earlier:
 
-```sh
+```shell
 docker run --name build -i --link=service-mysql:mysql --link=service-postgres:postgres ruby:2.6 /bin/bash < build_script
 ```
 
@@ -829,7 +829,7 @@ piped using STDIN to the bash interpreter which in turn executes the
 When you finish testing and no longer need the containers, you can remove them
 with:
 
-```sh
+```shell
 docker rm -f -v build service-mysql service-postgres
 ```
 

doc/ci/docker/using_kaniko.md

@@ -72,7 +72,7 @@ build:
 When trying to push to a Docker registry that uses a certificate that is signed
 by a custom CA, you might get the following error:
 
-```sh
+```shell
 $ /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --no-push
 INFO[0000] Downloading base image registry.gitlab.example.com/group/docker-image
 error building image: getting stage builder for stage 0: Get https://registry.gitlab.example.com/v2/: x509: certificate signed by unknown authority

doc/ci/enable_or_disable_ci.md

@@ -75,7 +75,7 @@ default_projects_features:
 
 Save the file and restart GitLab:
 
-```sh
+```shell
 sudo service gitlab restart
 ```
 
@@ -87,7 +87,7 @@ gitlab_rails['gitlab_default_projects_features_builds'] = false
 
 Save the file and reconfigure GitLab:
 
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
 

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -54,7 +54,7 @@ CI/CD from every new push to master. The `master` branch for this game's [reposi
 contains a completed version with all configurations. If you would like to follow along
 with this article, you can clone and work from the `devops-article` branch:
 
-```sh
+```shell
 git clone git@gitlab.com:blitzgren/gitlab-game-demo.git
 git checkout devops-article
 ```
@@ -363,7 +363,7 @@ our repository. If all goes well you'll end up with a green check mark on each j
 You can confirm that the tests passed by clicking on the `test` job to enter the full build logs.
 Scroll to the bottom and observe, in all its passing glory:
 
-```sh
+```shell
 $ gulp run-test
 [18:37:24] Using gulpfile /builds/blitzgren/gitlab-game-demo/gulpfile.js
 [18:37:24] Starting 'run-test'...

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

@@ -75,7 +75,7 @@ First install [Docker Engine](https://docs.docker.com/installation/).
 To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/index.html).
 You can use public runners available on `gitlab.com` or you can register your own:
 
-```sh
+```shell
 gitlab-runner register \
   --non-interactive \
   --url "https://gitlab.com/" \

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

@@ -66,7 +66,7 @@ First install [Docker Engine](https://docs.docker.com/installation/).
 To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/).
 You can use public runners available on `gitlab.com` or register your own:
 
-```sh
+```shell
 gitlab-runner register \
   --non-interactive \
   --url "https://gitlab.com/" \

doc/ci/ssh_keys/README.md

@@ -150,7 +150,7 @@ connection would fail if the public keys would not match).
 To find out the host keys of your server, run the `ssh-keyscan` command from a
 trusted network (ideally, from the private server itself):
 
-```sh
+```shell
 ## Use the domain name
 ssh-keyscan example.com
 

doc/development/architecture.md

@@ -504,7 +504,7 @@ To summarize here's the [directory structure of the `git` user home directory](.
 
 ### Processes
 
-```sh
+```shell
 ps aux | grep '^git'
 ```
 

doc/development/database_debugging.md

@@ -60,7 +60,7 @@ When running specs with the [Spring preloader](rake_tasks.md#speed-up-tests-rake
 the test database can get into a corrupted state. Trying to run the migration or
 dropping/resetting the test database has no effect.
 
-```sh
+```shell
 $ bundle exec spring rspec some_spec.rb
 ...
 Failure/Error: ActiveRecord::Migration.maintain_test_schema!
@@ -78,7 +78,7 @@ ActiveRecord::PendingMigrationError:
 
 To resolve, you can kill the spring server and app that lives between spec runs.
 
-```sh
+```shell
 $ ps aux | grep spring
 eric             87304   1.3  2.9  3080836 482596   ??  Ss   10:12AM   4:08.36 spring app    | gitlab | started 6 hours ago | test mode
 eric             37709   0.0  0.0  2518640   7524 s006  S    Wed11AM   0:00.79 spring server | gitlab | started 29 hours ago
@@ -100,6 +100,6 @@ of GitLab schema later than the `MIN_SCHEMA_VERSION`, and then rolled back the
 to an older migration, from before. In this case, in order to migrate forward again,
 you should set the `SKIP_SCHEMA_VERSION_CHECK` environment variable.
 
-```sh
+```shell
 bundle exec rake db:migrate SKIP_SCHEMA_VERSION_CHECK=true
 ```

doc/development/distributed_tracing.md

@@ -27,7 +27,7 @@ no overhead at all.
 To enable `GITLAB_TRACING`, a valid _"configuration-string"_ value should be set, with a URL-like
 form:
 
-```sh
+```shell
 GITLAB_TRACING=opentracing://<driver>?<param_name>=<param_value>&<param_name_2>=<param_value_2>
 ```
 
@@ -90,7 +90,7 @@ documentation](https://www.jaegertracing.io/docs/1.9/getting-started/).
 If you have Docker available, the easier approach to running the Jaeger all-in-one is through
 Docker, using the following command:
 
-```sh
+```shell
 $ docker run \
   --rm \
   -e COLLECTOR_ZIPKIN_HTTP_PORT=9411  \
@@ -121,7 +121,7 @@ appropriate configuration string.
 
 **TL;DR:** If you are running everything on the same host, use the following value:
 
-```sh
+```shell
 export GITLAB_TRACING="opentracing://jaeger?http_endpoint=http%3A%2F%2Flocalhost%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1"
 ```
 
@@ -152,7 +152,7 @@ application.
 
 When `GITLAB_TRACING` is configured properly, the application will log this on startup:
 
-```sh
+```shell
 13:41:53 gitlab-workhorse.1      | 2019/02/12 13:41:53 Tracing enabled
 ...
 13:41:54 gitaly.1                | 2019/02/12 13:41:54 Tracing enabled
@@ -161,7 +161,7 @@ When `GITLAB_TRACING` is configured properly, the application will log this on s
 
 If `GITLAB_TRACING` is not configured correctly, this will also be logged:
 
-```sh
+```shell
 13:43:45 gitaly.1                | 2019/02/12 13:43:45 skipping tracing configuration step: tracer: unable to load driver mytracer
 ```
 

doc/development/documentation/index.md

@@ -98,7 +98,7 @@ For example, if you move `doc/workflow/lfs/lfs_administration.md` to
    A quick way to find them is to use `git grep`. First go to the root directory
    where you cloned the `gitlab` repository and then do:
 
-   ```sh
+   ```shell
    git grep -n "workflow/lfs/lfs_administration"
    git grep -n "lfs/lfs_administration"
    ```
@@ -435,7 +435,7 @@ This list does not limit what other linters you can add to your local documentat
  documentation in the [`gitlab` project](https://gitlab.com/gitlab-org/gitlab), run the
  following commands from within the `gitlab` project:
 
-```sh
+```shell
 cd doc
 proselint **/*.md
 ```
@@ -480,13 +480,13 @@ run the following commands from within your `gitlab` project root directory, whi
 automatically detect the [`.markdownlint.json`](#markdownlint-configuration) config
 file in the root of the project, and test all files in `/doc` and its subdirectories:
 
-```sh
+```shell
 markdownlint 'doc/**/*.md'
 ```
 
 If you wish to use a different config file, use the `-c` flag:
 
-```sh
+```shell
 markdownlint -c <config-file-name> 'doc/**/*.md'
 ```
 

doc/development/documentation/site_architecture/release_process.md

@@ -23,7 +23,7 @@ and tag all tooling images locally:
 1. Make sure you're on the `dockerfiles/` directory of the `gitlab-docs` repo.
 1. Build the images:
 
-   ```sh
+   ```shell
    docker build -t registry.gitlab.com/gitlab-org/gitlab-docs:bootstrap -f Dockerfile.bootstrap ../
    docker build -t registry.gitlab.com/gitlab-org/gitlab-docs:builder-onbuild -f Dockerfile.builder.onbuild ../
    docker build -t registry.gitlab.com/gitlab-org/gitlab-docs:nginx-onbuild -f Dockerfile.nginx.onbuild ../
@@ -64,13 +64,13 @@ this needs to happen when the stable branches for all products have been created
 1. Make sure you're on the root path of the `gitlab-docs` repo.
 1. Make sure your `master` is updated:
 
-   ```sh
+   ```shell
    git pull origin master
    ```
 
 1. Run the raketask to create the single version:
 
-    ```sh
+    ```shell
     ./bin/rake "release:single[12.0]"
     ```
 
@@ -96,7 +96,7 @@ this needs to happen when the stable branches for all products have been created
 
 Optionally, you can test locally by building the image and running it:
 
-```sh
+```shell
 docker build -t docs:12.0 -f Dockerfile.12.0 .
 docker run -it --rm -p 4000:4000 docs:12.0
 ```
@@ -111,7 +111,7 @@ version and rotates the old one:
 1. Make sure you're on the root path of the `gitlab-docs` repo.
 1. Create a branch `release-X-Y`:
 
-   ```sh
+   ```shell
    git checkout master
    git checkout -b release-12-0
    ```
@@ -150,7 +150,7 @@ version and rotates the old one:
 1. In the end, there should be four files in total that have changed.
    Commit and push to create the merge request using the "Release" template:
 
-   ```sh
+   ```shell
    git add content/ Dockerfile.master dockerfiles/Dockerfile.archives
    git commit -m "Release 12.0"
    git push origin release-12-0
@@ -172,7 +172,7 @@ versions:
    pipelines succeed. The `release-X-Y` branch needs to be present locally,
    otherwise the raketask will fail:
 
-   ```sh
+   ```shell
    ./bin/rake release:dropdowns
    ```
 
@@ -218,7 +218,7 @@ from time to time.
 
 If this is not possible or there are many changes, merge master into them:
 
-```sh
+```shell
 git branch 12.0
 git fetch origin master
 git merge origin/master

doc/development/documentation/styleguide.md

@@ -329,7 +329,7 @@ where a reader must replace text with their own value.
 
 For example:
 
-```sh
+```shell
 cp <your_source_directory> <your_destination_directory>
 ```
 
@@ -1273,7 +1273,7 @@ METHOD /endpoint
 
 Example request:
 
-```sh
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/endpoint?parameters'
 ```
 

doc/development/emails.md

@@ -65,13 +65,13 @@ See the [Rails guides](https://guides.rubyonrails.org/action_mailer_basics.html#
 
 1. Run this command in the GitLab root directory to launch `mail_room`:
 
-   ```sh
+   ```shell
    bundle exec mail_room -q -c config/mail_room.yml
    ```
 
 1. Verify that everything is configured correctly:
 
-   ```sh
+   ```shell
    bundle exec rake gitlab:incoming_email:check RAILS_ENV=development
    ```
 

doc/development/fe_guide/frontend_faq.md

@@ -33,7 +33,7 @@ Find here the [source code setting the attribute](https://gitlab.com/gitlab-org/
 The `rake routes` command can be used to list all the routes available in the application, piping the output into `grep`, we can perform a search through the list of available routes.
 The output includes the request types available, route parameters and the relevant controller.
 
-```sh
+```shell
 bundle exec rake routes | grep "issues"
 ```
 

doc/development/feature_flags/controls.md

@@ -153,13 +153,13 @@ When a feature gate has been removed from the code base, the feature
 record still exists in the database that the flag was deployed too.
 The record can be deleted once the MR is deployed to each environment:
 
-```sh
+```shell
 /chatops run feature delete some_feature --dev
 /chatops run feature delete some_feature --staging
 ```
 
 Then, you can delete it from production after the MR is deployed to prod:
 
-```sh
+```shell
 /chatops run feature delete some_feature
 ```

doc/development/geo.md

@@ -244,7 +244,7 @@ Whenever a new Geo node is configured or the database schema changes on the
 **primary** node, you must refresh the foreign tables on the **secondary** node
 by running the following:
 
-```sh
+```shell
 bundle exec rake geo:db:refresh_foreign_tables
 ```
 

doc/development/gitaly.md

@@ -98,13 +98,13 @@ most commonly-used RPCs can be enabled via feature flags:
 A convenience Rake task can be used to enable or disable these flags
 all together. To enable:
 
-```sh
+```shell
 bundle exec rake gitlab:features:enable_rugged
 ```
 
 To disable:
 
-```sh
+```shell
 bundle exec rake gitlab:features:disable_rugged
 ```
 
@@ -343,7 +343,7 @@ the integration by using GDK:
       submitting commit, observing history, etc.).
    1. Check that the list of current metrics has the new counter for the feature flag:
 
-      ```sh
+      ```shell
       curl --silent http://localhost:9236/metrics | grep go_find_all_tags
       ```
 
@@ -352,7 +352,7 @@ the integration by using GDK:
    1. Navigate to GDK's root directory.
    1. Start a Rails console:
 
-      ```sh
+      ```shell
       bundle install && bundle exec rails console
       ```
 
@@ -373,6 +373,6 @@ the integration by using GDK:
       your changes (project creation, submitting commit, observing history, etc.).
    1. Verify the feature is on by observing the metrics for it:
 
-      ```sh
+      ```shell
       curl --silent http://localhost:9236/metrics | grep go_find_all_tags
       ```

doc/development/gotchas.md

@@ -43,7 +43,7 @@ end
 
 When run, this spec doesn't do what we might expect:
 
-```sh
+```shell
 1) API::API reproduce sequence issue creates a second label
    Failure/Error: expect(json_response.first['name']).to eq('label1')
 

doc/development/i18n/externalization.md

@@ -452,7 +452,7 @@ For more information, see the [`gl-sprintf`](https://gitlab-org.gitlab.io/gitlab
 Now that the new content is marked for translation, we need to update
 `locale/gitlab.pot` files with the following command:
 
-```sh
+```shell
 bin/rake gettext:regenerate
 ```
 
@@ -526,14 +526,14 @@ Let's suppose you want to add translations for a new language, let's say French.
 
 1. Next, you need to add the language:
 
-   ```sh
+   ```shell
    bin/rake gettext:add_language[fr]
    ```
 
    If you want to add a new language for a specific region, the command is similar,
    you just need to separate the region with an underscore (`_`). For example:
 
-   ```sh
+   ```shell
    bin/rake gettext:add_language[en_GB]
    ```
 
@@ -547,7 +547,7 @@ Let's suppose you want to add translations for a new language, let's say French.
    in order to generate the binary MO files and finally update the JSON files
    containing the translations:
 
-   ```sh
+   ```shell
    bin/rake gettext:compile
    ```
 
@@ -557,7 +557,7 @@ Let's suppose you want to add translations for a new language, let's say French.
 1. After checking that the changes are ok, you can proceed to commit the new files.
    For example:
 
-   ```sh
+   ```shell
    git add locale/fr/ app/assets/javascripts/locale/fr/
    git commit -m "Add French translations for Cycle Analytics page"
    ```

doc/development/import_project.md

@@ -30,7 +30,7 @@ Note that to use the script, it will require some preparation if you haven't don
 
 For details how to use `bin/import-project`, run:
 
-```sh
+```shell
 bin/import-project --help
 ```
 
@@ -53,7 +53,7 @@ As part of this script we also disable direct and background upload to avoid sit
 
 We can simply run this script from the terminal:
 
-```sh
+```shell
 bundle exec rake "gitlab:import_export:import[root, root, testingprojectimport, /path/to/file.tar.gz]"
 ```
 
@@ -63,7 +63,7 @@ The last option is to import a project using a Rails console:
 
 1. Start a Ruby on Rails console:
 
-   ```sh
+   ```shell
    # Omnibus GitLab
    gitlab-rails console
 
@@ -126,7 +126,7 @@ You can use this [snippet](https://gitlab.com/gitlab-org/gitlab/snippets/1924954
 
 You can execute the script from the `gdk/gitlab` directory like this:
 
-```sh
+```shell
 bundle exec rails r  /path_to_sript/script.rb project_name /path_to_extracted_project request_store_enabled
 ```
 

doc/development/internal_api.md

@@ -51,7 +51,7 @@ POST /internal/allowed
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --data "key_id=11&project=gnuwget/wget2&action=git-upload-pack&protocol=ssh" http://localhost:3001/api/v4/internal/allowed
 ```
 
@@ -99,7 +99,7 @@ information for LFS clients when the repository is accessed over SSH.
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --data "key_id=11&project=gnuwget/wget2" http://localhost:3001/api/v4/internal/lfs_authenticate
 ```
 
@@ -132,7 +132,7 @@ GET /internal/authorized_keys
 
 Example request:
 
-```sh
+```shell
 curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>""http://localhost:3001/api/v4/internal/authorized_keys?key=<key as passed by OpenSSH>"
 ```
 
@@ -167,7 +167,7 @@ GET /internal/discover
 
 Example request:
 
-```sh
+```shell
 curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>" "http://localhost:3001/api/v4/internal/discover?key_id=7"
 ```
 
@@ -196,7 +196,7 @@ GET /internal/check
 
 Example request:
 
-```sh
+```shell
 curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>" "http://localhost:3001/api/v4/internal/check"
 ```
 
@@ -232,7 +232,7 @@ GET /internal/two_factor_recovery_codes
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --data "key_id=7" http://localhost:3001/api/v4/internal/two_factor_recovery_codes
 ```
 
@@ -275,7 +275,7 @@ POST /internal/pre_receive
 
 Example request:
 
-```sh
+```shell
 curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --data "gl_repository=project-7" http://localhost:3001/api/v4/internal/pre_receive
 ```
 
@@ -307,7 +307,7 @@ POST /internal/post_receive
 
 Example Request:
 
-```sh
+```shell
 curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --data "gl_repository=project-7" --data "identifier=user-1" --data "changes=0000000000000000000000000000000000000000 fd9e76b9136bdd9fe217061b497745792fe5a5ee gh-pages\n"  http://localhost:3001/api/v4/internal/post_receive
 ```
 

doc/development/new_fe_guide/dependencies.md

@@ -17,13 +17,13 @@ production assets post-compile.
 
 To add or upgrade a dependency, run:
 
-```sh
+```shell
 yarn add <your dependency here>
 ```
 
 This may introduce duplicate dependencies. To de-duplicate `yarn.lock`, run:
 
-```sh
+```shell
 node_modules/.bin/yarn-deduplicate --list --strategy fewer yarn.lock && yarn install
 ```
 

doc/development/performance.md

@@ -123,7 +123,7 @@ Keeping that in mind, to create a profile, identify (or create) a spec that
 exercises the troublesome code path, then run it using the `bin/rspec-stackprof`
 helper, e.g.:
 
-```sh
+```shell
 $ LIMIT=10 bin/rspec-stackprof spec/policies/project_policy_spec.rb
 8/8 |====== 100 ======>| Time: 00:00:18
 
@@ -157,14 +157,14 @@ it calls, were being executed.
 
 To create a graphical view of the call stack:
 
-```sh
+```shell
 stackprof tmp/project_policy_spec.rb.dump --graphviz > project_policy_spec.dot
 dot -Tsvg project_policy_spec.dot > project_policy_spec.svg
 ```
 
 To load the profile in [kcachegrind](https://kcachegrind.github.io/):
 
-```sh
+```shell
 stackprof tmp/project_policy_spec.dump --callgrind > project_policy_spec.callgrind
 kcachegrind project_policy_spec.callgrind # Linux
 qcachegrind project_policy_spec.callgrind # Mac
@@ -172,7 +172,7 @@ qcachegrind project_policy_spec.callgrind # Mac
 
 It may be useful to zoom in on a specific method, e.g.:
 
-```sh
+```shell
 $ stackprof tmp/project_policy_spec.rb.dump --method warm_asset_cache
 TestEnv#warm_asset_cache (/Users/lupine/dev/gitlab.com/gitlab-org/gitlab-development-kit/gitlab/spec/support/test_env.rb:164)
   samples:     0 self (0.0%)  /   6288 total (36.9%)
@@ -225,7 +225,7 @@ may have changed over time.
 
 To activate profiling in your local environment, run the following:
 
-```sh
+```shell
 export RSPEC_PROFILING=yes
 rake rspec_profiling:install
 ```
@@ -237,7 +237,7 @@ variable set.
 Ad-hoc investigation of the collected results can be performed in an interactive
 shell:
 
-```sh
+```shell
 $ rake rspec_profiling:console
 irb(main):001:0> results.count
 => 231
@@ -271,7 +271,7 @@ bundle exec rbtrace -p <PID> -e 'File.open("heap.json", "wb") { |t| ObjectSpace.
 
 Having the JSON, you finally could render a picture using the script [provided by Aaron](https://gist.github.com/tenderlove/f28373d56fdd03d8b514af7191611b88) or similar:
 
-```sh
+```shell
 ruby heapviz.rb heap.json
 ```
   

doc/development/profiling.md

@@ -99,7 +99,7 @@ Sherlock is a custom profiling tool built into GitLab. Sherlock is _only_
 available when running GitLab in development mode _and_ when setting the
 environment variable `ENABLE_SHERLOCK` to a non empty value. For example:
 
-```sh
+```shell
 ENABLE_SHERLOCK=1 bundle exec rails s
 ```
 
@@ -112,7 +112,7 @@ Bullet adds quite a bit of logging noise it's disabled by default. To enable
 Bullet, set the environment variable `ENABLE_BULLET` to a non-empty value before
 starting GitLab. For example:
 
-```sh
+```shell
 ENABLE_BULLET=true bundle exec rails s
 ```
 

doc/development/shell_commands.md

@@ -211,7 +211,7 @@ Since there are no anchors in the used regular expression, the `git:/tmp/lol` in
 
 When importing, GitLab would execute the following command, passing the `import_url` as an argument:
 
-```sh
+```shell
 git clone file://git:/tmp/lol
 ```
 

doc/development/testing_guide/best_practices.md

@@ -36,7 +36,7 @@ Here are some things to keep in mind regarding test performance:
 
 To run rspec tests:
 
-```sh
+```shell
 # run all tests
 bundle exec rspec
 
@@ -46,7 +46,7 @@ bundle exec rspec spec/[path]/[to]/[spec].rb
 
 Use [guard](https://github.com/guard/guard) to continuously monitor for changes and only run matching tests:
 
-```sh
+```shell
 bundle exec guard
 ```
 

doc/downgrade_ee_to_ce/README.md

@@ -47,13 +47,13 @@ to avoid getting this error, you need to remove all instances of the
 
 **Omnibus Installation**
 
-```sh
+```shell
 sudo gitlab-rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all"
 ```
 
 **Source Installation**
 
-```sh
+```shell
 bundle exec rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all" production
 ```
 
@@ -89,7 +89,7 @@ To downgrade a source installation, you need to replace the current remote of
 your GitLab installation with the Community Edition's remote, fetch the latest
 changes, and checkout the latest stable branch:
 
-```sh
+```shell
 git remote set-url origin git@gitlab.com:gitlab-org/gitlab-foss.git
 git fetch --all
 git checkout 8-x-stable

doc/gitlab-basics/add-file.md

@@ -22,7 +22,7 @@ Open a [terminal/shell](command-line-commands.md), and change into the folder of
 GitLab project. This usually means running the following command until you get
 to the desired destination:
 
-```sh
+```shell
 cd <destination folder>
 ```
 
@@ -38,7 +38,7 @@ in Windows), put the file into a directory within the GitLab project.
 Check if your file is actually present in the directory (if you are in Windows,
 use `dir` instead):
 
-```sh
+```shell
 ls
 ```
 
@@ -46,33 +46,33 @@ You should see the name of the file in the list shown.
 
 Check the status:
 
-```sh
+```shell
 git status
 ```
 
 Your file's name should appear in red, so `git` took notice of it! Now add it
 to the repository:
 
-```sh
+```shell
 git add <name of file>
 ```
 
 Check the status again, your file's name should have turned green:
 
-```sh
+```shell
 git status
 ```
 
 Commit (save) your file to the repository:
 
-```sh
+```shell
 git commit -m "DESCRIBE COMMIT IN A FEW WORDS"
 ```
 
 Now you can push (send) your changes (in the branch `<branch-name>`) to GitLab
 (the Git remote named 'origin'):
 
-```sh
+```shell
 git push origin <branch-name>
 ```
 

doc/gitlab-basics/create-project.md

@@ -119,7 +119,7 @@ set to Private by default (you can later change it in the [project's settings](.
 
 This can be done by using either SSH or HTTPS:
 
-```sh
+```shell
 ## Git push using SSH
 git push --set-upstream git@gitlab.example.com:namespace/nonexistent-project.git master
 

doc/install/aws/index.md

@@ -418,13 +418,13 @@ To find the host or endpoint, naviagate to **Amazon RDS > Databases** and click
 
 Do not to include the colon and port number:
 
-```sh
+```shell
 sudo /opt/gitlab/embedded/bin/psql -U gitlab -h <rds-endpoint> -d gitlabhq_production
 ```
 
 At the psql prompt create the extension and then quit the session:
 
-```sh
+```shell
 psql (10.9)
 Type "help" for help.
 
@@ -474,14 +474,14 @@ gitlab_rails['redis_port'] = 6379
 
 Finally, reconfigure GitLab for the change to take effect:
 
-```sh
+```shell
 sudo gitlab-ctl reconfigure
 ```
 
 You might also find it useful to run a check and a service status to make sure
 everything has been setup correctly:
 
-```sh
+```shell
 sudo gitlab-rake gitlab:check
 sudo gitlab-ctl status
 ```
@@ -507,7 +507,7 @@ The EBS volume will host the Git repositories data:
 
 1. Save the file and reconfigure GitLab:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 
@@ -548,7 +548,7 @@ After you SSH into the instance, configure the domain name:
 
 1. Reconfigure GitLab:
 
-   ```sh
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
 
@@ -601,7 +601,7 @@ To back up GitLab:
 1. SSH into your instance.
 1. Take a backup:
 
-   ```sh
+   ```shell
    sudo gitlab-backup create
    ```
 
@@ -622,7 +622,7 @@ released, you can update your GitLab instance:
 1. SSH into your instance
 1. Take a backup:
 
-   ```sh
+   ```shell
    sudo gitlab-backup create
    ```
 
@@ -631,7 +631,7 @@ For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
 
 1. Update the repositories and install GitLab:
 
-   ```sh
+   ```shell
    sudo apt update
    sudo apt install gitlab-ee
    ```

doc/install/digitaloceandocker.md

@@ -47,13 +47,13 @@ The rest of the steps are identical for macOS and Linux.
 
 1. Set the DO token:
 
-   ```sh
+   ```shell
    export DOTOKEN=<your generated token>
    ```
 
 1. Create the machine:
 
-   ```sh
+   ```shell
    docker-machine create \
      --driver digitalocean \
      --digitalocean-access-token=$DOTOKEN \
@@ -71,7 +71,7 @@ In this example we'll create a GitLab EE 8.10.8 instance.
 
 First connect the docker client to the docker host you created previously.
 
-```sh
+```shell
 eval "$(docker-machine env gitlab-test-env-do)"
 ```
 
@@ -88,7 +88,7 @@ You can add this to your `~/.bash_profile` file to ensure the `docker` client us
 
 #### Set up container settings
 
-```sh
+```shell
 export SSH_PORT=2222
 export HTTP_PORT=8888
 export VERSION=8.10.8-ee.0
@@ -97,7 +97,7 @@ export NAME=gitlab-test-8.10
 
 #### Create container
 
-```sh
+```shell
 docker run --detach \
 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://$(docker-machine ip gitlab-test-env-do):$HTTP_PORT'; gitlab_rails['gitlab_shell_ssh_port'] = $SSH_PORT;" \
 --hostname $(docker-machine ip gitlab-test-env-do) \
@@ -110,7 +110,7 @@ gitlab/gitlab-ee:$VERSION
 
 #### Retrieve the docker host IP
 
-```sh
+```shell
 docker-machine ip gitlab-test-env-do
 # example output: 192.168.151.134
 ```
@@ -119,11 +119,11 @@ Browse to: `http://192.168.151.134:8888/`.
 
 #### Execute interactive shell/edit configuration
 
-```sh
+```shell
 docker exec -it $NAME /bin/bash
 ```
 
-```sh
+```shell
 # example commands
 root@192:/# vi /etc/gitlab/gitlab.rb
 root@192:/# gitlab-ctl reconfigure

doc/install/openshift_and_gitlab/index.md

@@ -68,7 +68,7 @@ In short:
 
 1. Open a terminal and in a new directory run:
 
-   ```sh
+   ```shell
    vagrant init openshift/origin-all-in-one
    ```
 
@@ -76,7 +76,7 @@ In short:
 1. In the same directory where you generated the Vagrantfile
    enter:
 
-   ```sh
+   ```shell
    vagrant up
    ```
 
@@ -120,7 +120,7 @@ functionalities.
 
 Let's first see the version of `oc`:
 
-```sh
+```shell
 $ oc version
 
 oc v1.3.0
@@ -136,7 +136,7 @@ when we visited the web console earlier. The username/password for the
 administrator user is `admin/admin`. There is also a test user with username/
 password `user/user`, with limited access. Let's login as admin for the moment:
 
-```sh
+```shell
 $ oc login https://10.2.2.2:8443
 
 Authentication required for https://10.2.2.2:8443 (openshift)
@@ -158,13 +158,13 @@ Using project "default".
 
 Switch to the `openshift-infra` project with:
 
-```sh
+```shell
 oc project openshift-infra
 ```
 
 And finally, see its status:
 
-```sh
+```shell
 oc status
 ```
 
@@ -193,20 +193,20 @@ In that case, the OpenShift service might not be running, so in order to fix it:
 1. SSH into the VM by going to the directory where the Vagrantfile is and then
    run:
 
-   ```sh
+   ```shell
    vagrant ssh
    ```
 
 1. Run `systemctl` and verify by the output that the `openshift` service is not
    running (it will be in red color). If that's the case start the service with:
 
-   ```sh
+   ```shell
    sudo systemctl start openshift
    ```
 
 1. Verify the service is up with:
 
-   ```sh
+   ```shell
    systemctl status openshift -l
    ```
 
@@ -233,7 +233,7 @@ or by using the web interface:
 If you used the command line, `oc` automatically uses the new project and you
 can see its status with:
 
-```sh
+```shell
 $ oc status
 
 In project gitlab on server https://10.2.2.2:8443
@@ -391,13 +391,13 @@ Let's see how to do that using the following steps.
 
 1. Make sure you are in the `gitlab` project:
 
-   ```sh
+   ```shell
    oc project gitlab
    ```
 
 1. See what services are used for this project:
 
-   ```sh
+   ```shell
    oc get svc
    ```
 
@@ -413,7 +413,7 @@ Let's see how to do that using the following steps.
 1. We need to see the replication controllers of the `gitlab-ce` service.
    Get a detailed view of the current ones:
 
-   ```sh
+   ```shell
    oc describe rc gitlab-ce
    ```
 
@@ -424,13 +424,13 @@ Let's see how to do that using the following steps.
 
 1. Scale GitLab using the previous information:
 
-   ```sh
+   ```shell
    oc scale --replicas=2 replicationcontrollers gitlab-ce-2
    ```
 
 1. Get the new replicas number to make sure scaling worked:
 
-   ```sh
+   ```shell
    oc get rc gitlab-ce-2
    ```
 
@@ -476,7 +476,7 @@ For OpenShift v3.0, you will need to do this manually:
 
 1. Edit the Security Context:
 
-   ```sh
+   ```shell
    oc edit scc anyuid
    ```
 
@@ -488,7 +488,7 @@ For OpenShift v3.0, you will need to do this manually:
 
 For OpenShift v3.1 and above, you can do:
 
-```sh
+```shell
 oc adm policy add-scc-to-user anyuid system:serviceaccount:gitlab:gitlab-ce-user
 ```
 

doc/integration/auth0.md

@@ -32,13 +32,13 @@ application.
 
    For Omnibus package:
 
-   ```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/integration/azure.md

@@ -34,13 +34,13 @@ To enable the Microsoft Azure OAuth2 OmniAuth provider you must register your ap
 
    For Omnibus package:
 
-   ```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/integration/cas.md

@@ -6,13 +6,13 @@ To enable the CAS OmniAuth provider you must register your application with your
 
    For Omnibus package:
 
-   ```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/integration/elasticsearch.md

@@ -68,7 +68,7 @@ installed before running `make`.
 
 To install on Debian or Ubuntu, run:
 
-```sh
+```shell
 sudo apt install libicu-dev
 ```
 
@@ -76,7 +76,7 @@ sudo apt install libicu-dev
 
 To install on CentOS or RHEL, run:
 
-```sh
+```shell
 sudo yum install libicu-devel
 ```
 
@@ -84,7 +84,7 @@ sudo yum install libicu-devel
 
 To install on macOS, run:
 
-```sh
+```shell
 brew install icu4c
 export PKG_CONFIG_PATH="/usr/local/opt/icu4c/lib/pkgconfig:$PKG_CONFIG_PATH"
 ```
@@ -93,7 +93,7 @@ export PKG_CONFIG_PATH="/usr/local/opt/icu4c/lib/pkgconfig:$PKG_CONFIG_PATH"
 
 To build and install the indexer, run:
 
-```sh
+```shell
 indexer_path=/home/git/gitlab-elasticsearch-indexer
 
 # Run the installation task for gitlab-elasticsearch-indexer:
@@ -108,7 +108,7 @@ Please remember to pass the `-E` flag to `sudo` if you do so.
 
 Example:
 
-```sh
+```shell
 PREFIX=/usr sudo -E make install
 ```
 
@@ -184,7 +184,7 @@ To disable the Elasticsearch integration:
 1. Click **Save changes** for the changes to take effect.
 1. (Optional) Delete the existing index by running one of these commands:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:delete_index
 
@@ -206,7 +206,7 @@ To index via the Admin Area:
 1. [Configure your Elasticsearch host and port](#enabling-elasticsearch).
 1. Create empty indexes using one of the following commands:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:create_empty_index
 
@@ -219,7 +219,7 @@ To index via the Admin Area:
 1. Click **Check progress** in the confirmation message to see the status of the background jobs.
 1. Personal snippets need to be indexed manually by running one of these commands:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index_snippets
 
@@ -241,7 +241,7 @@ If the database size is less than 500 MiB, and the size of all hosted repos is l
 1. [Enable **Elasticsearch indexing** and configure your host and port](#enabling-elasticsearch).
 1. Index your data using one of the following commands:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index
 
@@ -261,7 +261,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
 1. [Configure your Elasticsearch host and port](#enabling-elasticsearch).
 1. Create empty indexes using one of the following commands:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:create_empty_index
 
@@ -284,7 +284,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
 
 1. Index projects and their associated data:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index_projects
 
@@ -296,7 +296,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
    You can view the jobs in **Admin Area > Monitoring > Background Jobs > Queues Tab**
    and click `elastic_indexer`, or you can query indexing status using a rake task:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index_projects_status
 
@@ -309,7 +309,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
    If you want to limit the index to a range of projects you can provide the
    `ID_FROM` and `ID_TO` parameters:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=1001 ID_TO=2000
 
@@ -331,7 +331,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
    it will check every project repository again to make sure that every commit in
    a repository is indexed, which can be useful in case if your index is outdated:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index_projects UPDATE_INDEX=true ID_TO=1000
 
@@ -346,7 +346,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
 1. Personal snippets are not associated with a project and need to be indexed separately
    by running one of these commands:
 
-   ```sh
+   ```shell
    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:index_snippets
 
@@ -437,7 +437,7 @@ In addition to the rake tasks, there are some environment variables that can be
 
 Because the `ID_TO` and `ID_FROM` environment variables use the `or equal to` comparison, you can index only one project by using both these variables with the same project ID number:
 
-```sh
+```shell
 root@git:~# sudo gitlab-rake gitlab:elastic:index_projects ID_TO=5 ID_FROM=5
 Indexing project repositories...I, [2019-03-04T21:27:03.083410 #3384]  INFO -- : Indexing GitLab User / test (ID=33)...
 I, [2019-03-04T21:27:05.215266 #3384]  INFO -- : Indexing GitLab User / test (ID=33) is done!