Add latest changes from gitlab-org/gitlab@master

19 files changed, 82 insertions, 81 deletions

diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
index dd474b09a9c..e013078fa2e 100644
--- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
@@ -65,7 +65,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
    Create a file `build_status` and insert the script below and run
    `chmod +x build_status` in your terminal to make the script executable.
 
-   ```bash
+   ```shell
    #!/usr/bin/env bash
 
    # Push GitLab CI/CD build status to Bitbucket Cloud
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index b7d708b152e..2750e61ff96 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -16,7 +16,7 @@ One of the new trends in Continuous Integration/Deployment is to:
 It's also useful when your application already has the `Dockerfile` that can be
 used to create and test an image:
 
-```bash
+```shell
 docker build -t my-image dockerfiles/
 docker run my-image /script/to/run/tests
 docker tag my-image my-registry:5000/my-image
@@ -48,7 +48,7 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user.
 
 1. During GitLab Runner installation select `shell` as method of executing job scripts or use command:
 
-   ```bash
+   ```shell
    sudo gitlab-runner register -n \
      --url https://gitlab.com/ \
      --registration-token REGISTRATION_TOKEN \
@@ -63,13 +63,13 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user.
 
 1. Add `gitlab-runner` user to `docker` group:
 
-   ```bash
+   ```shell
    sudo usermod -aG docker gitlab-runner
    ```
 
 1. Verify that `gitlab-runner` has access to Docker:
 
-   ```bash
+   ```shell
    sudo -u gitlab-runner -H docker info
    ```
 
@@ -160,7 +160,7 @@ support this.
 1. Register GitLab Runner from the command line to use `docker` and `privileged`
    mode:
 
-   ```bash
+   ```shell
    sudo gitlab-runner register -n \
      --url https://gitlab.com/ \
      --registration-token REGISTRATION_TOKEN \
@@ -320,7 +320,7 @@ In order to do that, follow the steps:
 
 1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`:
 
-   ```bash
+   ```shell
    sudo gitlab-runner register -n \
      --url https://gitlab.com/ \
      --registration-token REGISTRATION_TOKEN \
@@ -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
 ```
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index 8c6069bd939..630beec453c 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -28,7 +28,7 @@ to use the `docker` executor.
 
 A one-line example can be seen below:
 
-```bash
+```shell
 sudo gitlab-runner register \
   --url "https://gitlab.example.com/" \
   --registration-token "PROJECT_REGISTRATION_TOKEN" \
@@ -559,7 +559,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
 
 - **First way -** Do a `docker login` on your local machine:
 
-  ```bash
+  ```shell
   docker login registry.example.com:5000 --username my_username --password my_password
   ```
 
@@ -568,7 +568,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
   If you don't need access to the registry from your computer, you
   can do a `docker logout`:
 
-  ```bash
+  ```shell
   docker logout registry.example.com:5000
   ```
 
@@ -579,7 +579,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
   `${username}:${password}` and create the Docker configuration JSON manually.
   Open a terminal and execute the following command:
 
-  ```bash
+  ```shell
   echo -n "my_username:my_password" | base64
 
   # Example output to copy
@@ -790,7 +790,7 @@ able to run Docker with your regular user account.
 
 First start with creating a file named `build_script`:
 
-```bash
+```shell
 cat <<EOF > build_script
 git clone https://gitlab.com/gitlab-org/gitlab-runner.git /builds/gitlab-org/gitlab-runner
 cd /builds/gitlab-org/gitlab-runner
@@ -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
 ```
 
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index 45afd9c6223..dce5cd5b40d 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/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
diff --git a/doc/ci/enable_or_disable_ci.md b/doc/ci/enable_or_disable_ci.md
index 7c7640e23c3..732b4676c56 100644
--- a/doc/ci/enable_or_disable_ci.md
+++ b/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
 ```
 
diff --git a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
index 788d57b81f8..946deb6a5ff 100644
--- a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
+++ b/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'...
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index 5acdd273548..b8f191570bc 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -57,7 +57,7 @@ This test is as simple as asserting that the given value is true.
 Laravel uses `PHPUnit` for tests by default.
 If we run `vendor/bin/phpunit` we should see the green output:
 
-```bash
+```shell
 vendor/bin/phpunit
 OK (1 test, 1 assertions)
 ```
@@ -70,7 +70,7 @@ Since we have our app up and running locally, it's time to push the codebase to
 Let's create [a new project](../../../gitlab-basics/create-project.md) in GitLab named `laravel-sample`.
 After that, follow the command line instructions displayed on the project's homepage to initiate the repository on our machine and push the first commit.
 
-```bash
+```shell
 cd laravel-sample
 git init
 git remote add origin git@gitlab.example.com:<USERNAME>/laravel-sample.git
@@ -89,7 +89,7 @@ We have installed LEMP stack which stands for Linux, NGINX, MySQL and PHP on our
 Let's now create a new user that will be used to deploy our website and give it
 the needed permissions using [Linux ACL](https://serversforhackers.com/c/linux-acls):
 
-```bash
+```shell
 # Create user deployer
 sudo adduser deployer
 # Give the read-write-execute permissions to deployer user for directory /var/www
@@ -98,7 +98,7 @@ sudo setfacl -R -m u:deployer:rwx /var/www
 
 If you don't have ACL installed on your Ubuntu server, use this command to install it:
 
-```bash
+```shell
 sudo apt install acl
 ```
 
@@ -108,7 +108,7 @@ Let's suppose we want to deploy our app to the production server from a private
 
 After that, we need to copy the private key, which will be used to connect to our server as the deployer user with SSH, to be able to automate our deployment process:
 
-```bash
+```shell
 # As the deployer user on server
 #
 # Copy the content of public key to authorized_keys
@@ -128,7 +128,7 @@ We'll use this variable in the `.gitlab-ci.yml` later, to easily connect to our
 
 We also need to add the public key to **Project** > **Settings** > **Repository** as a [Deploy Key](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project).
 
-```bash
+```shell
 # As the deployer user on the server
 #
 # Copy the public key
@@ -141,7 +141,7 @@ To the field **Title**, add any name you want, and paste the public key into the
 
 Now, let's clone our repository on the server just to make sure the `deployer` user has access to the repository.
 
-```bash
+```shell
 # As the deployer user on server
 #
 git clone git@gitlab.example.com:<USERNAME>/laravel-sample.git
@@ -157,7 +157,7 @@ Now, let's make sure our web server configuration points to the `current/public`
 
 Open the default NGINX server block configuration file by typing:
 
-```bash
+```shell
 sudo nano /etc/nginx/sites-available/default
 ```
 
@@ -199,7 +199,7 @@ Then within our `@task` directive we define the bash commands that should be run
 
 On the local machine use the `run` command to run Envoy tasks.
 
-```bash
+```shell
 envoy run list
 ```
 
@@ -382,7 +382,7 @@ Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/lara
 To keep things simple, we commit directly to `master`, without using [feature-branches](../../../topics/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
 In a real world project, teams may use [Issue Tracker](../../../user/project/issues/index.md) and [Merge Requests](../../../user/project/merge_requests/index.md) to move their code across branches:
 
-```bash
+```shell
 git add Envoy.blade.php
 git commit -m 'Add Envoy'
 git push origin master
@@ -407,7 +407,7 @@ With Docker images our builds run incredibly faster!
 
 Let's create a [Dockerfile](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Dockerfile) in the root directory of our app with the following content:
 
-```bash
+```shell
 # Set the base image for subsequent instructions
 FROM php:7.1
 
@@ -449,13 +449,13 @@ You may need to [enable Container Registry](../../../user/packages/container_reg
 
 To start using Container Registry on our machine, we first need to login to the GitLab registry using our GitLab username and password:
 
-```bash
+```shell
 docker login registry.gitlab.com
 ```
 
 Then we can build and push our image to GitLab:
 
-```bash
+```shell
 docker build -t registry.gitlab.com/<USERNAME>/laravel-sample .
 
 docker push registry.gitlab.com/<USERNAME>/laravel-sample
@@ -475,7 +475,7 @@ We'll use this image further down in the `.gitlab-ci.yml` configuration file to
 
 Let's commit the `Dockerfile` file.
 
-```bash
+```shell
 git add Dockerfile
 git commit -m 'Add Dockerfile'
 git push origin master
diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md
index 1dd3049d53d..db039b746e3 100644
--- a/doc/ci/examples/php.md
+++ b/doc/ci/examples/php.md
@@ -40,7 +40,7 @@ done.
 Let's create a `ci/docker_install.sh` file in the root directory of our
 repository with the following content:
 
-```bash
+```shell
 #!/bin/bash
 
 # We need to install dependencies only for Docker
@@ -153,7 +153,7 @@ dependencies are installed.
 For example, in a VM running Debian 8 we first update the cache, then we
 install `phpunit` and `php5-mysql`:
 
-```bash
+```shell
 sudo apt-get update -y
 sudo apt-get install -y phpunit php5-mysql
 ```
@@ -198,7 +198,7 @@ some extensions that are not currently present on the build machine.
 
 To install additional extensions simply execute:
 
-```bash
+```shell
 pecl install <extension>
 ```
 
@@ -269,7 +269,7 @@ documentation.
 With GitLab Runner 1.0 you can also test any changes locally. From your
 terminal execute:
 
-```bash
+```shell
 # Check using docker executor
 gitlab-runner exec docker test:app
 
diff --git a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
index 03381dc16ff..6d05c37390a 100644
--- a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
+++ b/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/" \
diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
index 66246a0fda2..3de8f3c675c 100644
--- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
+++ b/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/" \
diff --git a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
index f91e89d3c4c..557ebad72ba 100644
--- a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
+++ b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
@@ -79,7 +79,7 @@ When we call `mix` command, we'll pass two arguments:
 - And the parameter `phoenix.new` requires, which is the name of the new project. In this case,
   we're calling it `hello_gitlab_ci`, but you're free to set your own name:
 
-```bash
+```shell
 mix phoenix.new hello_gitlab_ci
 ```
 
@@ -108,14 +108,14 @@ changes.
 
 Run the commands below to create our empty database:
 
-```bash
+```shell
 cd hello_gitlab_ci
 mix ecto.create
 ```
 
 We expect to see this output at the end of the command:
 
-```bash
+```shell
 Generated hello_gitlab_ci app
 The database for HelloGitlabCi.Repo has been created
 ```
@@ -130,13 +130,13 @@ permissions and a password of `postgres`. If it's not your case, check
 Now, it's time to see if everything we did until now went well. We'll call `mix` again, this time
 with `phoenix.server` parameter, which will start Phoenix's HTTP Server.
 
-```bash
+```shell
 mix phoenix.server
 ```
 
 This will be the output to this command:
 
-```bash
+```shell
 [info] Running HelloGitlabCi.Endpoint with Cowboy using http://localhost:4000
 23 May 11:44:35 - info: compiling
 23 May 11:44:37 - info: compiled 6 files into 2 files, copied 3 in 9.8 sec
@@ -223,13 +223,13 @@ Let's run a new task with `mix` to run those tests for us. This time, the parame
 
 In your terminal, navigate to the directory `hello_gitlab_ci` and run:
 
-```bash
+```shell
 mix test
 ```
 
 Our expected result is this:
 
-```bash
+```shell
 ....
 
 Finished in 0.7 seconds
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
index fca6916bee4..744713b0678 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
@@ -30,6 +30,7 @@ Pipelines invalidated through failures are immediately canceled and requeued.
 
 Merge trains have the following requirements and limitations:
 
+- GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher to run Merge Trains.
 - This feature requires that
   [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are
   **configured properly**.
diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md
index 43cc7eeab8c..90efae30925 100644
--- a/doc/ci/quick_start/README.md
+++ b/doc/ci/quick_start/README.md
@@ -128,7 +128,7 @@ For more information and a complete `.gitlab-ci.yml` syntax, please read
 Once you've created `.gitlab-ci.yml`, you should add it to your Git repository
 and push it to GitLab.
 
-```bash
+```shell
 git add .gitlab-ci.yml
 git commit -m "Add .gitlab-ci.yml"
 git push origin master
diff --git a/doc/ci/services/mysql.md b/doc/ci/services/mysql.md
index ce69a7df885..e21b62e93cf 100644
--- a/doc/ci/services/mysql.md
+++ b/doc/ci/services/mysql.md
@@ -56,7 +56,7 @@ GitLab Runner with the Shell executor.
 
 First install the MySQL server:
 
-```bash
+```shell
 sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev
 ```
 
@@ -68,7 +68,7 @@ the root user.*
 
 The next step is to create a user, so login to MySQL as root:
 
-```bash
+```shell
 mysql -u root -p
 ```
 
@@ -77,38 +77,38 @@ application. Change `$password` in the command below to a real strong password.
 
 *Note: Do not type `mysql>`, this is part of the MySQL prompt.*
 
-```bash
+```shell
 mysql> CREATE USER 'runner'@'localhost' IDENTIFIED BY '$password';
 ```
 
 Create the database:
 
-```bash
+```shell
 mysql> CREATE DATABASE IF NOT EXISTS `<your_mysql_database>` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
 ```
 
 Grant the necessary permissions on the database:
 
-```bash
+```shell
 mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, CREATE TEMPORARY TABLES, DROP, INDEX, ALTER, LOCK TABLES ON `<your_mysql_database>`.* TO 'runner'@'localhost';
 ```
 
 If all went well you can now quit the database session:
 
-```bash
+```shell
 mysql> \q
 ```
 
 Now, try to connect to the newly created database to check that everything is
 in place:
 
-```bash
+```shell
 mysql -u runner -p -D <your_mysql_database>
 ```
 
 As a final step, configure your application to use the database, for example:
 
-```bash
+```shell
 Host: localhost
 User: runner
 Password: $password
diff --git a/doc/ci/services/postgres.md b/doc/ci/services/postgres.md
index 142f4f262e5..a137f10949f 100644
--- a/doc/ci/services/postgres.md
+++ b/doc/ci/services/postgres.md
@@ -57,13 +57,13 @@ GitLab Runner with the Shell executor.
 
 First install the PostgreSQL server:
 
-```bash
+```shell
 sudo apt-get install -y postgresql postgresql-client libpq-dev
 ```
 
 The next step is to create a user, so login to PostgreSQL:
 
-```bash
+```shell
 sudo -u postgres psql -d template1
 ```
 
@@ -72,7 +72,7 @@ application. Change `$password` in the command below to a real strong password.
 
 *__Note:__ Do not type `template1=#`, this is part of the PostgreSQL prompt.*
 
-```bash
+```shell
 template1=# CREATE USER runner WITH PASSWORD '$password' CREATEDB;
 ```
 
@@ -83,20 +83,20 @@ testing framework you have tools that drop and create databases.*
 
 Create the database and grant all privileges on it for the user `runner`:
 
-```bash
+```shell
 template1=# CREATE DATABASE nice_marmot OWNER runner;
 ```
 
 If all went well you can now quit the database session:
 
-```bash
+```shell
 template1=# \q
 ```
 
 Now, try to connect to the newly created database with the user `runner` to
 check that everything is in place.
 
-```bash
+```shell
 psql -U runner -h localhost -d nice_marmot -W
 ```
 
diff --git a/doc/ci/services/redis.md b/doc/ci/services/redis.md
index ccb92fa94d7..b04b36f7a04 100644
--- a/doc/ci/services/redis.md
+++ b/doc/ci/services/redis.md
@@ -40,13 +40,13 @@ Runner with the Shell executor.
 
 In your build machine install the Redis server:
 
-```bash
+```shell
 sudo apt-get install redis-server
 ```
 
 Verify that you can connect to the server with the `gitlab-runner` user:
 
-```bash
+```shell
 # Try connecting the Redis server
 sudo -u gitlab-runner -H redis-cli
 
diff --git a/doc/ci/ssh_keys/README.md b/doc/ci/ssh_keys/README.md
index bee1501aed8..62a8bb23e08 100644
--- a/doc/ci/ssh_keys/README.md
+++ b/doc/ci/ssh_keys/README.md
@@ -134,7 +134,7 @@ on, and use that key for all projects that are run on this machine.
 
 Once done, try to login to the remote server in order to accept the fingerprint:
 
-```bash
+```shell
 ssh example.com
 ```
 
@@ -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
 
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
index 1a58e3eb7a2..08b2171f23b 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -137,7 +137,7 @@ below.
 
 By using cURL you can trigger a pipeline rerun with minimal effort, for example:
 
-```bash
+```shell
 curl --request POST \
      --form token=TOKEN \
      --form ref=master \
@@ -148,7 +148,7 @@ In this case, the project with ID `9` will get rebuilt on `master` branch.
 
 Alternatively, you can pass the `token` and `ref` arguments in the query string:
 
-```bash
+```shell
 curl --request POST \
     "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=master"
 ```
@@ -241,7 +241,7 @@ upload_package:
 You can then trigger a rebuild while you pass the `UPLOAD_TO_S3` variable
 and the script of the `upload_package` job will run:
 
-```bash
+```shell
 curl --request POST \
   --form token=TOKEN \
   --form ref=master \
@@ -259,7 +259,7 @@ Whether you craft a script or just run cURL directly, you can trigger jobs
 in conjunction with cron. The example below triggers a job on the `master`
 branch of project with ID `9` every night at `00:30`:
 
-```bash
+```shell
 30 0 * * * curl --request POST --form token=TOKEN --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline
 ```
 
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index ff602de6754..1fdf8009fcd 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -74,7 +74,7 @@ file path as a command line argument or an environment variable. In the past, th
 common pattern was to read the value of a CI variable, save it in a file, and then
 use the newly created file in your script:
 
-```bash
+```shell
 # Read certificate stored in $KUBE_CA_PEM variable and save it in a new file
 echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
 # Pass the newly created file to kubectl
@@ -90,7 +90,7 @@ it directly. For example, let's say we have the following variables:
 
 We can then call them from `.gitlab-ci.yml` like this:
 
-```bash
+```shell
 kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM"
 ```
 
@@ -259,7 +259,7 @@ job_name:
 
 Example values:
 
-```bash
+```shell
 export CI_JOB_ID="50"
 export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
 export CI_COMMIT_SHORT_SHA="1ecfd275"
@@ -623,7 +623,7 @@ job_name:
 
 Example truncated output with `CI_DEBUG_TRACE` set to `true`:
 
-```bash
+```shell
 ...
 
 export CI_SERVER_TLS_CA_FILE="/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE"