Add latest changes from gitlab-org/gitlab@master

doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md

@@ -48,7 +48,7 @@ Fire up a terminal, navigate to your Git repository and:
 1. Disable `git-annex`:
-   ```bash
+   ```shell
    git annex sync --content
    git annex direct
    git annex uninit
@@ -85,7 +85,7 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Backup your repository
-   ```bash
+   ```shell
    cd repository
    git annex sync --content
    cd ..
@@ -97,14 +97,14 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Use `annex direct`:
-   ```bash
+   ```shell
    cd repository
    git annex direct
    ```
    The output should be similar to this:
-   ```bash
+   ```shell
    commit
    On branch master
    Your branch is up-to-date with 'origin/master'.
@@ -116,13 +116,13 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Disable Git Annex with [`annex uninit`][uninit]:
-   ```bash
+   ```shell
    git annex uninit
    ```
    The output should be similar to this:
-   ```bash
+   ```shell
    unannex debian.iso ok
    Deleted branch git-annex (was 2534d2c).
    ```
@@ -131,13 +131,13 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Switch back to `indirect` mode:
-   ```bash
+   ```shell
    git annex indirect
    ```
    The output should be similar to this:
-   ```bash
+   ```shell
    (merging origin/git-annex into git-annex...)
    (recording state in git...)
    commit  (recording state in git...)
@@ -165,7 +165,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
 1. First, make sure you have `git-lfs` installed locally:
-   ```bash
+   ```shell
    git lfs help
    ```
@@ -174,7 +174,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
 1. Inside the repo, run the following command to initiate LFS:
-   ```bash
+   ```shell
    git lfs install
    ```
@@ -182,7 +182,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
    can track specific files, all files containing the same extension, or an
    entire directory:
-   ```bash
+   ```shell
    git lfs track images/01.png   # per file
    git lfs track **/*.png        # per extension
    git lfs track images/         # per directory
@@ -194,7 +194,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
 1. Add the files, commit and push them to GitLab:
-   ```bash
+   ```shell
    git add .
    git commit -m "commit message"
    git push
@@ -217,7 +217,7 @@ branches created by Git Annex: `git-annex`, and all under `synced/`.
 You can also do this on the command line with:
-```bash
+```shell
 git branch -d synced/master
 git branch -d synced/git-annex
 git push origin :synced/master
@@ -229,7 +229,7 @@ git remote prune origin
 If there are still some Annex objects inside your repository (`.git/annex/`)
 or references inside `.git/config`, run `annex uninit` again:
-```bash
+```shell
 git annex uninit
 ```

doc/administration/monitoring/performance/gitlab_configuration.md

@@ -17,7 +17,7 @@ changes.
 Finally, a restart of all GitLab processes is required for the changes to take
 effect:
-```bash
+```shell
 # For Omnibus installations
 sudo gitlab-ctl restart

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/monitoring/performance/influxdb_configuration.md

@@ -110,14 +110,14 @@ buffer size is set to the same value, the default value is almost never enough.
 To set the OS buffer size to 200 MB, on Linux you can run the following command:
-```bash
+```shell
 sysctl -w net.core.rmem_max=209715200
 ```
 To make this permanent, add the following to `/etc/sysctl.conf` and restart the
 server:
-```bash
+```shell
 net.core.rmem_max=209715200
 ```
@@ -154,7 +154,7 @@ and password (`-password <password>`)  you set earlier to the commands below._
 Run the following command to create a database named `gitlab`:
-```bash
+```shell
 influx -execute 'CREATE DATABASE gitlab'
 ```
@@ -162,7 +162,7 @@ The name **must** be `gitlab`, do not use any other name.
 Next, make sure that the database was successfully created:
-```bash
+```shell
 influx -execute 'SHOW DATABASES'
 ```

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
    ```
@@ -207,7 +207,7 @@ For debugging purposes, you can start extra Sidekiq processes by using the comma
 `/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster`. This command
 takes arguments using the following syntax:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
 ```
@@ -225,14 +225,14 @@ For example, say you want to start 2 extra processes: one to process the
 `process_commit` queue, and one to process the `post_receive` queue. This can be
 done as follows:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit post_receive
 ```
 If you instead want to start one process processing both queues, you'd use the
 following syntax:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive
 ```
@@ -240,7 +240,7 @@ If you want to have one Sidekiq process dealing with the `process_commit` and
 `post_receive` queues, and one process to process the `gitlab_shell` queue,
 you'd use the following:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive gitlab_shell
 ```
@@ -272,7 +272,7 @@ The `sidekiq-cluster` command can store its PID in a file. By default no PID
 file is written, but this can be changed by passing the `--pidfile` option to
 `sidekiq-cluster`. For example:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit
 ```

doc/administration/operations/fast_ssh_key_lookup.md

@@ -60,7 +60,7 @@ AuthorizedKeysCommandUser git
 Reload OpenSSH:
-```bash
+```shell
 # Debian or Ubuntu installations
 sudo service ssh reload

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/container_registry.md

@@ -169,7 +169,7 @@ If your certificate provider provides the CA Bundle certificates, append them to
 Users should now be able to login to the Container Registry with their GitLab
 credentials using:
-```bash
+```shell
 docker login gitlab.example.com:4567
 ```
@@ -194,7 +194,7 @@ Let's assume that you want the container Registry to be accessible at
    `/etc/gitlab/ssl/registry.gitlab.example.com.key` and make sure they have
    correct permissions:
-   ```bash
+   ```shell
    chmod 600 /etc/gitlab/ssl/registry.gitlab.example.com.*
    ```
@@ -234,7 +234,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
 Users should now be able to login to the Container Registry using their GitLab
 credentials:
-```bash
+```shell
 docker login registry.gitlab.example.com
 ```
@@ -793,7 +793,7 @@ After adding the setting, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitl
 Use curl to request debug output from the debug server:
-```bash
+```shell
 curl localhost:5001/debug/health
 curl localhost:5001/debug/vars
 ```

doc/administration/packages/index.md

@@ -166,12 +166,12 @@ The processing will be done in a background worker and requires **no downtime**.
 For Omnibus GitLab:
-```sh
+```shell
 sudo gitlab-rake "gitlab:packages:migrate"
 ```
 For installations from source:
-```bash
+```shell
 RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:packages:migrate
 ```

doc/administration/pages/index.md

@@ -360,14 +360,14 @@ that method from working. Use the following workaround:
 1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
-    ```bash
+    ```shell
     printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
     echo -n | openssl s_client -connect gitlab-domain-example.com:443  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
     ```
 1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
-    ```bash
+    ```shell
     sudo gitlab-ctl restart gitlab-pages
     ```

doc/administration/pages/source.md

@@ -98,7 +98,7 @@ The Pages daemon doesn't listen to the outside world.
 1. Install the Pages daemon:
-   ```bash
+   ```shell
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -108,7 +108,7 @@ The Pages daemon doesn't listen to the outside world.
 1. Go to the GitLab installation directory:
-   ```bash
+   ```shell
    cd /home/git/gitlab
    ```
@@ -138,7 +138,7 @@ The Pages daemon doesn't listen to the outside world.
 1. Copy the `gitlab-pages` NGINX configuration file:
-   ```bash
+   ```shell
    sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
    sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf
    ```
@@ -160,7 +160,7 @@ outside world.
 1. Install the Pages daemon:
-   ```bash
+   ```shell
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -170,7 +170,7 @@ outside world.
 1. In `gitlab.yml`, set the port to `443` and https to `true`:
-   ```bash
+   ```shell
    ## GitLab Pages
    pages:
      enabled: true
@@ -195,7 +195,7 @@ outside world.
 1. Copy the `gitlab-pages-ssl` NGINX configuration file:
-   ```bash
+   ```shell
    sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
    sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf
    ```
@@ -225,7 +225,7 @@ world. Custom domains are supported, but no TLS.
 1. Install the Pages daemon:
-   ```bash
+   ```shell
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -263,7 +263,7 @@ world. Custom domains are supported, but no TLS.
 1. Copy the `gitlab-pages-ssl` NGINX configuration file:
-   ```bash
+   ```shell
    sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
    sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf
    ```
@@ -290,7 +290,7 @@ world. Custom domains and TLS are supported.
 1. Install the Pages daemon:
-   ```bash
+   ```shell
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -332,7 +332,7 @@ world. Custom domains and TLS are supported.
 1. Copy the `gitlab-pages-ssl` NGINX configuration file:
-   ```bash
+   ```shell
    sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
    sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf
    ```

doc/administration/pseudonymizer.md

@@ -85,7 +85,7 @@ You can optionally run the pseudonymizer using the following environment variabl
 - `PSEUDONYMIZER_OUTPUT_DIR` - where to store the output CSV files (defaults to `/tmp`)
 - `PSEUDONYMIZER_BATCH` - the batch size when querying the DB (defaults to `100000`)
-```bash
+```shell
 ## Omnibus
 sudo gitlab-rake gitlab:db:pseudonymizer

doc/administration/raketasks/check.md

@@ -33,13 +33,13 @@ integrity check described previously.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:git:fsck
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:git:fsck RAILS_ENV=production
 ```
@@ -58,7 +58,7 @@ Currently, integrity checks are supported for the following types of file:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:artifacts:check
 sudo gitlab-rake gitlab:lfs:check
 sudo gitlab-rake gitlab:uploads:check
@@ -66,7 +66,7 @@ sudo gitlab-rake gitlab:uploads:check
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:artifacts:check RAILS_ENV=production
 sudo -u git -H bundle exec rake gitlab:lfs:check RAILS_ENV=production
 sudo -u git -H bundle exec rake gitlab:uploads:check RAILS_ENV=production
@@ -82,7 +82,7 @@ Variable  | Type    | Description
 `ID_TO`   | integer | Specifies the ID value to end at, inclusive of the value.
 `VERBOSE` | boolean | Causes failures to be listed individually, rather than being summarized.
-```bash
+```shell
 sudo gitlab-rake gitlab:artifacts:check BATCH=100 ID_FROM=50 ID_TO=250
 sudo gitlab-rake gitlab:lfs:check BATCH=100 ID_FROM=50 ID_TO=250
 sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
@@ -90,7 +90,7 @@ sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
 Example output:
-```bash
+```shell
 $ sudo gitlab-rake gitlab:uploads:check
 Checking integrity of Uploads
 - 1..1350: Failures: 0
@@ -107,7 +107,7 @@ Done!
 Example verbose output:
-```bash
+```shell
 $ sudo gitlab-rake gitlab:uploads:check VERBOSE=1
 Checking integrity of Uploads
 - 1..1350: Failures: 0

doc/administration/raketasks/geo.md

@@ -11,13 +11,13 @@ This is equivalent of running `git repack -d` on a _bare_ repository.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake geo:git:housekeeping:incremental_repack
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake geo:git:housekeeping:incremental_repack RAILS_ENV=production
 ```
@@ -29,13 +29,13 @@ when this is enabled in GitLab.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake geo:git:housekeeping:full_repack
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake geo:git:housekeeping:full_repack RAILS_ENV=production
 ```
@@ -46,13 +46,13 @@ a reachability bitmap index when this is enabled in GitLab.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake geo:git:housekeeping:gc
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake geo:git:housekeeping:gc RAILS_ENV=production
 ```
@@ -63,12 +63,12 @@ can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake geo:run_orphaned_project_registry_cleaner
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake geo:run_orphaned_project_registry_cleaner RAILS_ENV=production
 ```

doc/administration/raketasks/github_import.md

@@ -16,7 +16,7 @@ before/after the brackets. Also, Some shells (e.g., zsh) can interpret the open/
 To import a project from the list of your GitHub projects available:
-```bash
+```shell
 # Omnibus installations
 sudo gitlab-rake "import:github[access_token,root,foo/bar]"
@@ -32,7 +32,7 @@ will get created from your GitHub project. Subgroups are also possible: `foo/foo
 To import a specific GitHub project (named `foo/github_repo` here):
-```bash
+```shell
 # Omnibus installations
 sudo gitlab-rake "import:github[access_token,root,foo/bar,foo/github_repo]"

doc/administration/raketasks/ldap.md

@@ -9,20 +9,20 @@ using the command below.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:ldap:check
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
 ```
 By default, the task will return a sample of 100 LDAP users. Change this
 limit by passing a number to the check task:
-```bash
+```shell
 rake gitlab:ldap:check[50]
 ```
@@ -41,13 +41,13 @@ instead.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:ldap:group_sync
 ```
 **Source Installation**
-```bash
+```shell
 bundle exec rake gitlab:ldap:group_sync
 ```
@@ -79,13 +79,13 @@ as the `old_provider` and the correct provider as the `new_provider`.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider]
 ```
 **Source Installation**
-```bash
+```shell
 bundle exec rake gitlab:ldap:rename_provider[old_provider,new_provider] RAILS_ENV=production
 ```
@@ -95,7 +95,7 @@ Consider beginning with the default server ID `main` (full provider `ldapmain`).
 If we change `main` to `mycompany`, the `new_provider` is `ldapmycompany`.
 To rename all user identities run the following command:
-```bash
+```shell
 sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany]
 ```
@@ -116,13 +116,13 @@ for them:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:ldap:rename_provider
 ```
 **Source Installation**
-```bash
+```shell
 bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production
 ```
@@ -136,6 +136,6 @@ What is the new provider? Ex. 'ldapcustom': ldapmycompany
 This tasks also accepts the `force` environment variable which will skip the
 confirmation dialog:
-```bash
+```shell
 sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider] force=yes
 ```

doc/administration/raketasks/maintenance.md

@@ -6,13 +6,13 @@ This command gathers information about your GitLab installation and the System i
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:env:info
 ```
 **Source Installation**
-```bash
+```shell
 bundle exec rake gitlab:env:info RAILS_ENV=production
 ```
@@ -66,13 +66,13 @@ You may also have a look at our Troubleshooting Guides:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:check
 ```
 **Source Installation**
-```bash
+```shell
 bundle exec rake gitlab:check RAILS_ENV=production
 ```
@@ -129,13 +129,13 @@ In some case it is necessary to rebuild the `authorized_keys` file.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:shell:setup
 ```
 **Source Installation**
-```bash
+```shell
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
 ```
@@ -153,13 +153,13 @@ clear Redis' cache.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake cache:clear
 ```
 **Source Installation**
-```bash
+```shell
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
 ```
@@ -174,7 +174,7 @@ Omnibus packages.
 **Source Installation**
-```bash
+```shell
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
 ```
@@ -194,13 +194,13 @@ in the GitLab Performance Monitoring database.
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:track_deployment
 ```
 **Source Installation**
-```bash
+```shell
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
 ```
@@ -213,13 +213,13 @@ is included to help you with this:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:tcp_check[example.com,80]
 ```
 **Source Installation**
-```bash
+```shell
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
 ```
@@ -238,13 +238,13 @@ To clear all exclusive leases:
 DANGER: **DANGER**:
 Don't run it while GitLab or Sidekiq is running
-```bash
+```shell
 sudo gitlab-rake gitlab:exclusive_lease:clear
 ```
 To specify a lease `type` or lease `type + id`, specify a scope:
-```bash
+```shell
 # to clear all leases for repository garbage collection:
 sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*]
@@ -256,14 +256,14 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]
 To check the status of migrations, you can use the following rake task:
-```bash
+```shell
 sudo gitlab-rake db:migrate:status
 ```
 This will output a table with a `Status` of `up` or `down` for
 each Migration ID.
-```bash
+```shell
 database: gitlabhq_production
  Status   Migration ID    Migration Name
@@ -279,6 +279,6 @@ This could be as a result of [updating existing metrics](../../development/prome
 To re-import the metrics you can run:
-```bash
+```shell
 sudo gitlab-rake metrics:setup_common_metrics
 ```

doc/administration/raketasks/project_import_export.md

@@ -13,7 +13,7 @@
 The GitLab Import/Export version can be checked by using:
-```bash
+```shell
 # Omnibus installations
 sudo gitlab-rake gitlab:import_export:version
@@ -23,7 +23,7 @@ bundle exec rake gitlab:import_export:version RAILS_ENV=production
 The current list of DB tables that will get exported can be listed by using:
-```bash
+```shell
 # Omnibus installations
 sudo gitlab-rake gitlab:import_export:data

doc/administration/raketasks/storage.md

@@ -16,19 +16,19 @@ This task will schedule all your existing projects and attachments associated wi
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:migrate_to_hashed
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:migrate_to_hashed RAILS_ENV=production
 ```
 They both also accept a range as environment variable:
-```bash
+```shell
 # to migrate any non migrated project from ID 20 to 50.
 export ID_FROM=20
 export ID_TO=50
@@ -63,19 +63,19 @@ Legacy storage type.
 For Omnibus installations, run the following:
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:rollback_to_legacy
 ```
 For source installations, run the following:
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:rollback_to_legacy RAILS_ENV=production
 ```
 Both commands accept a range as environment variable:
-```bash
+```shell
 # to rollback any migrated project from ID 20 to 50.
 export ID_FROM=20
 export ID_TO=50
@@ -95,13 +95,13 @@ To have a simple summary of projects using **Legacy** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:legacy_projects
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:legacy_projects RAILS_ENV=production
 ```
@@ -109,13 +109,13 @@ To list projects using **Legacy** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:list_legacy_projects
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:list_legacy_projects RAILS_ENV=production
 ```
@@ -126,13 +126,13 @@ To have a simple summary of projects using **Hashed** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:hashed_projects
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:hashed_projects RAILS_ENV=production
 ```
@@ -140,13 +140,13 @@ To list projects using **Hashed** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:list_hashed_projects
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:list_hashed_projects RAILS_ENV=production
 ```
@@ -156,13 +156,13 @@ To have a simple summary of project attachments using **Legacy** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:legacy_attachments
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:legacy_attachments RAILS_ENV=production
 ```
@@ -170,13 +170,13 @@ To list project attachments using **Legacy** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:list_legacy_attachments
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:list_legacy_attachments RAILS_ENV=production
 ```
@@ -186,13 +186,13 @@ To have a simple summary of project attachments using **Hashed** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:hashed_attachments
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:hashed_attachments RAILS_ENV=production
 ```
@@ -200,13 +200,13 @@ To list project attachments using **Hashed** storage:
 **Omnibus Installation**
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:list_hashed_attachments
 ```
 **Source Installation**
-```bash
+```shell
 sudo -u git -H bundle exec rake gitlab:storage:list_hashed_attachments RAILS_ENV=production
 ```

doc/administration/raketasks/uploads/migrate.md

@@ -17,13 +17,13 @@ described in the next section.
 **Omnibus Installation**
-```bash
+```shell
 gitlab-rake "gitlab:uploads:migrate:all"
 ```
 **Source Installation**
-```bash
+```shell
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate:all
 ```
@@ -52,7 +52,7 @@ Variable | Type | Description
 **Omnibus Installation**
-```bash
+```shell
 # gitlab-rake gitlab:uploads:migrate[uploader_class, model_class, mount_point]
 # Avatars
@@ -80,7 +80,7 @@ gitlab-rake "gitlab:uploads:migrate[FileUploader, MergeRequest]"
 >**Note:**
 Use `RAILS_ENV=production` for every task.
-```bash
+```shell
 # sudo -u git -H bundle exec rake gitlab:uploads:migrate
 # Avatars
@@ -112,13 +112,13 @@ To migrate all uploads created by legacy uploaders, run:
 **Omnibus Installation**
-```bash
+```shell
 gitlab-rake gitlab:uploads:legacy:migrate
 ```
 **Source Installation**
-```bash
+```shell
 bundle exec rake gitlab:uploads:legacy:migrate
 ```
@@ -145,13 +145,13 @@ keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`.
 **Omnibus Installation**
-```bash
+```shell
 gitlab-rake "gitlab:uploads:migrate_to_local:all"
 ```
 **Source Installation**
-```bash
+```shell
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate_to_local:all
 ```