Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/lib/graphql.js

@@ -5,6 +5,14 @@ import { ApolloLink } from 'apollo-link';
 import { BatchHttpLink } from 'apollo-link-batch-http';
 import csrf from '~/lib/utils/csrf';
 
+export const fetchPolicies = {
+  CACHE_FIRST: 'cache-first',
+  CACHE_AND_NETWORK: 'cache-and-network',
+  NETWORK_ONLY: 'network-only',
+  NO_CACHE: 'no-cache',
+  CACHE_ONLY: 'cache-only',
+};
+
 export default (resolvers = {}, config = {}) => {
   let uri = `${gon.relative_url_root}/api/graphql`;
 
@@ -32,5 +40,10 @@ export default (resolvers = {}, config = {}) => {
     }),
     resolvers,
     assumeImmutableResults: config.assumeImmutableResults,
+    defaultOptions: {
+      query: {
+        fetchPolicy: config.fetchPolicy || fetchPolicies.CACHE_FIRST,
+      },
+    },
   });
 };

app/assets/javascripts/monitoring/stores/utils.js

 import { omit } from 'lodash';
-import createGqClient from '~/lib/graphql';
+import createGqClient, { fetchPolicies } from '~/lib/graphql';
 import { getIdFromGraphQLId } from '~/graphql_shared/utils';
 
-export const gqClient = createGqClient();
+export const gqClient = createGqClient(
+  {},
+  {
+    fetchPolicy: fetchPolicies.NO_CACHE,
+  },
+);
 
 export const uniqMetricsId = metric => `${metric.metric_id}_${metric.id}`;
 

app/assets/stylesheets/pages/diff.scss

@@ -63,11 +63,6 @@
       background-color: $gray-normal;
     }
 
-    a,
-    button {
-      color: $gray-700;
-    }
-
     svg {
       vertical-align: middle;
       top: -1px;

app/finders/projects/serverless/functions_finder.rb

@@ -4,9 +4,15 @@ module Projects
   module Serverless
     class FunctionsFinder
       include Gitlab::Utils::StrongMemoize
+      include ReactiveCaching
 
       attr_reader :project
 
+      self.reactive_cache_key = ->(finder) { finder.cache_key }
+      self.reactive_cache_worker_finder = ->(_id, *args) { from_cache(*args) }
+
+      MAX_CLUSTERS = 10
+
       def initialize(project)
         @project = project
       end
@@ -15,8 +21,9 @@ module Projects
         knative_services.flatten.compact
       end
 
-      # Possible return values: Clusters::KnativeServicesFinder::KNATIVE_STATE
       def knative_installed
+        return knative_installed_from_cluster?(*cache_key) if available_environments.empty?
+
         states = services_finders.map do |finder|
           finder.knative_detected.tap do |state|
             return state if state == ::Clusters::KnativeServicesFinder::KNATIVE_STATES['checking'] # rubocop:disable Cop/AvoidReturnFromBlocks
@@ -45,8 +52,41 @@ module Projects
         end
       end
 
+      def self.from_cache(project_id)
+        project = Project.find(project_id)
+
+        new(project)
+      end
+
+      def cache_key(*args)
+        [project.id]
+      end
+
+      def calculate_reactive_cache(*)
+        # rubocop: disable CodeReuse/ActiveRecord
+        project.all_clusters.enabled.take(MAX_CLUSTERS).any? do |cluster|
+          cluster.kubeclient.knative_client.discover
+        rescue Kubeclient::ResourceNotFoundError
+          next
+        end
+      end
+
       private
 
+      def knative_installed_from_cluster?(*cache_key)
+        cached_data = with_reactive_cache_memoized(*cache_key) { |data| data }
+
+        return ::Clusters::KnativeServicesFinder::KNATIVE_STATES['checking'] if cached_data.nil?
+
+        cached_data ? true : false
+      end
+
+      def with_reactive_cache_memoized(*cache_key)
+        strong_memoize(:reactive_cache) do
+          with_reactive_cache(*cache_key) { |data| data }
+        end
+      end
+
       def knative_service(environment_scope, name)
         finders_for_scope(environment_scope).map do |finder|
           services = finder
@@ -95,6 +135,10 @@ module Projects
           environment_scope == finder.cluster.environment_scope
         end
       end
+
+      def id
+        nil
+      end
     end
   end
 end

app/helpers/explore_helper.rb

@@ -19,6 +19,18 @@ module ExploreHelper
     request_path_with_options(options)
   end
 
+  def filter_audit_path(options = {})
+    exist_opts = {
+      entity_type: params[:entity_type],
+      entity_id: params[:entity_id],
+      created_before: params[:created_before],
+      created_after: params[:created_after],
+      sort: params[:sort]
+    }
+    options = exist_opts.merge(options).delete_if { |key, value| value.blank? }
+    request_path_with_options(options)
+  end
+
   def filter_groups_path(options = {})
     request_path_with_options(options)
   end

app/helpers/sorting_helper.rb

@@ -207,6 +207,13 @@ module SortingHelper
     }.merge(issuable_sort_option_overrides)
   end
 
+  def audit_logs_sort_order_hash
+    {
+      sort_value_recently_created => sort_title_recently_created,
+      sort_value_oldest_created   => sort_title_oldest_created
+    }
+  end
+
   def issuable_sort_option_title(sort_value)
     sort_value = issuable_sort_option_overrides[sort_value] || sort_value
 

app/models/audit_event.rb

@@ -13,6 +13,8 @@ class AuditEvent < ApplicationRecord
 
   scope :by_entity_type, -> (entity_type) { where(entity_type: entity_type) }
   scope :by_entity_id, -> (entity_id) { where(entity_id: entity_id) }
+  scope :order_by_id_desc, -> { order(id: :desc) }
+  scope :order_by_id_asc, -> { order(id: :asc) }
 
   after_initialize :initialize_details
 

app/models/clusters/applications/runner.rb

@@ -3,7 +3,7 @@
 module Clusters
   module Applications
     class Runner < ApplicationRecord
-      VERSION = '0.13.0'
+      VERSION = '0.13.1'
 
       self.table_name = 'clusters_applications_runners'
 

app/services/akismet_service.rb

-# frozen_string_literal: true
-
-class AkismetService
-  attr_accessor :text, :options
-
-  def initialize(owner_name, owner_email, text, options = {})
-    @owner_name = owner_name
-    @owner_email = owner_email
-    @text = text
-    @options = options
-  end
-
-  def spam?
-    return false unless akismet_enabled?
-
-    params = {
-      type: 'comment',
-      text: text,
-      created_at: DateTime.now,
-      author: owner_name,
-      author_email: owner_email,
-      referrer: options[:referrer]
-    }
-
-    begin
-      is_spam, is_blatant = akismet_client.check(options[:ip_address], options[:user_agent], params)
-      is_spam || is_blatant
-    rescue => e
-      Rails.logger.error("Unable to connect to Akismet: #{e}, skipping check") # rubocop:disable Gitlab/RailsLogger
-      false
-    end
-  end
-
-  def submit_ham
-    submit(:ham)
-  end
-
-  def submit_spam
-    submit(:spam)
-  end
-
-  private
-
-  attr_accessor :owner_name, :owner_email
-
-  def akismet_client
-    @akismet_client ||= ::Akismet::Client.new(Gitlab::CurrentSettings.akismet_api_key,
-                                              Gitlab.config.gitlab.url)
-  end
-
-  def akismet_enabled?
-    Gitlab::CurrentSettings.akismet_enabled
-  end
-
-  def submit(type)
-    return false unless akismet_enabled?
-
-    params = {
-      type: 'comment',
-      text: text,
-      author: owner_name,
-      author_email: owner_email
-    }
-
-    begin
-      akismet_client.public_send(type, options[:ip_address], options[:user_agent], params) # rubocop:disable GitlabSecurity/PublicSend
-      true
-    rescue => e
-      Rails.logger.error("Unable to connect to Akismet: #{e}, skipping!") # rubocop:disable Gitlab/RailsLogger
-      false
-    end
-  end
-end

app/services/concerns/akismet_methods.rb

@@ -6,7 +6,7 @@ module AkismetMethods
   end
 
   def akismet
-    @akismet ||= AkismetService.new(
+    @akismet ||= Spam::AkismetService.new(
       spammable_owner.name,
       spammable_owner.email,
       spammable.spammable_text,

app/services/notes/update_service.rb

@@ -3,7 +3,7 @@
 module Notes
   class UpdateService < BaseService
     def execute(note)
-      return note unless note.editable?
+      return note unless note.editable? && params.present?
 
       old_mentioned_users = note.mentioned_users(current_user).to_a
 

app/services/spam/akismet_service.rb

+# frozen_string_literal: true
+
+module Spam
+  class AkismetService
+    attr_accessor :text, :options
+
+    def initialize(owner_name, owner_email, text, options = {})
+      @owner_name = owner_name
+      @owner_email = owner_email
+      @text = text
+      @options = options
+    end
+
+    def spam?
+      return false unless akismet_enabled?
+
+      params = {
+        type: 'comment',
+        text: text,
+        created_at: DateTime.now,
+        author: owner_name,
+        author_email: owner_email,
+        referrer: options[:referrer]
+      }
+
+      begin
+        is_spam, is_blatant = akismet_client.check(options[:ip_address], options[:user_agent], params)
+        is_spam || is_blatant
+      rescue => e
+        Rails.logger.error("Unable to connect to Akismet: #{e}, skipping check") # rubocop:disable Gitlab/RailsLogger
+        false
+      end
+    end
+
+    def submit_ham
+      submit(:ham)
+    end
+
+    def submit_spam
+      submit(:spam)
+    end
+
+    private
+
+    attr_accessor :owner_name, :owner_email
+
+    def akismet_client
+      @akismet_client ||= ::Akismet::Client.new(Gitlab::CurrentSettings.akismet_api_key,
+                                                Gitlab.config.gitlab.url)
+    end
+
+    def akismet_enabled?
+      Gitlab::CurrentSettings.akismet_enabled
+    end
+
+    def submit(type)
+      return false unless akismet_enabled?
+
+      params = {
+        type: 'comment',
+        text: text,
+        author: owner_name,
+        author_email: owner_email
+      }
+
+      begin
+        akismet_client.public_send(type, options[:ip_address], options[:user_agent], params) # rubocop:disable GitlabSecurity/PublicSend
+        true
+      rescue => e
+        Rails.logger.error("Unable to connect to Akismet: #{e}, skipping!") # rubocop:disable Gitlab/RailsLogger
+        false
+      end
+    end
+  end
+end

app/views/shared/boards/components/_board.html.haml

@@ -22,7 +22,7 @@
           %span.board-title-main-text.block-truncated{ "v-if": "list.type !== \"label\"",
             ":title" => '((list.label && list.label.description) || list.title || "")',
             data: { container: "body" },
-            ":class": "{ 'has-tooltip': !['backlog', 'closed'].includes(list.type) }" }
+            ":class": "{ 'has-tooltip': !['backlog', 'closed'].includes(list.type), 'd-block': list.type === 'milestone' }" }
             {{ list.title }}
 
           %span.board-title-sub-text.prepend-left-5.has-tooltip{ "v-if": "list.type === \"assignee\"",

changelogs/unreleased/197309-milestone-in-issue-boards-list-not-cropped-when-longer-than-board-.yml

+---
+title: Allow long milestone titles on board lists to be truncated
+merge_request:
+author:
+type: fixed

changelogs/unreleased/198411-jira-http-error.yml

+---
+title: Fix JIRA::HTTPError initialize parameter
+merge_request: 24060
+author:
+type: fixed

changelogs/unreleased/199526-new-mr-changes-tab-edit-file-button-ui-polish.yml

+---
+title: Remove gray color from diff buttons
+merge_request: 24041
+author:
+type: fixed

changelogs/unreleased/refactoring-entities-file-5.yml

+---
+title: Add separate classes for project related classes
+merge_request: 23887
+author: Rajendra Kadam
+type: added

changelogs/unreleased/update-gitlab-runner-helm-chart-to-0-13-1.yml

+---
+title: Update GitLab Runner Helm Chart to 0.13.1 (GitLab Runner 12.7.1)
+merge_request: 23588
+author:
+type: other

config/initializers/rails_host_authorization.rb

+# frozen_string_literal: true
+
+# This file requires config/initializers/1_settings.rb
+
+if Rails.env.development?
+  Rails.application.config.hosts << Gitlab.config.gitlab.host
+end

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-ee.md

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

doc/administration/auth/ldap.md

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

doc/administration/auth/oidc.md

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

doc/administration/auth/okta.md

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

doc/administration/file_hooks.md

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

doc/administration/geo/disaster_recovery/background_verification.md

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

doc/administration/geo/disaster_recovery/bring_primary_back.md

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

doc/administration/geo/disaster_recovery/index.md

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

doc/administration/geo/disaster_recovery/planned_failover.md

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

doc/administration/geo/replication/configuration.md

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

doc/administration/geo/replication/database.md

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

doc/administration/geo/replication/docker_registry.md

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

doc/administration/geo/replication/external_database.md

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

doc/administration/geo/replication/high_availability.md

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

doc/administration/geo/replication/remove_geo_node.md

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

doc/administration/geo/replication/troubleshooting.md

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

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

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

doc/administration/geo/replication/version_specific_updates.md

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

doc/administration/git_annex.md

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

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",
@@ -1009,7 +1009,7 @@ If you are having trouble connecting to a Gitaly node with command line (CLI) to
 
 Verify that you can reach Gitaly via TCP:
 
-```bash
+```shell
 sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]
 ```
 
@@ -1019,7 +1019,7 @@ If you use proxy servers in your command line environment, such as Bash, these c
 
 If you use Bash or a compatible command line environment, run the following commands to determine whether you have proxy servers configured:
 
-```bash
+```shell
 echo $http_proxy
 echo $https_proxy
 ```
@@ -1028,7 +1028,7 @@ If either of these variables have a value, your Gitaly CLI connections may be ge
 
 To remove the proxy setting, run the following commands (depending on which variables had values):
 
-```bash
+```shell
 unset http_proxy
 unset https_proxy
 ```

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
    ```
@@ -186,7 +186,7 @@ single NFS mount point as you normally would in `/etc/fstab`. Let's assume your
 NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in
 `/etc/fstab`:
 
-```bash
+```shell
 /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
 /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
 /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0

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/high_availability/redis.md

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

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

@@ -11,6 +11,6 @@ increasing the `local_markdown_version` setting in application settings.  This c
 be done by [changing the application settings through
 the API](../api/settings.md#change-application-settings):
 
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?local_markdown_version=<increased_number>
 ```

doc/administration/job_artifacts.md

@@ -156,7 +156,7 @@ _The artifacts are stored by default in
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
 
-   ```bash
+   ```shell
    gitlab-rake gitlab:artifacts:migrate
    ```
 
@@ -184,7 +184,7 @@ _The artifacts are stored by default in
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
 
-   ```bash
+   ```shell
    sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
    ```
 
@@ -239,7 +239,7 @@ you can flip the feature flag from a Rails console.
 
 1. Enter the Rails console:
 
-   ```sh
+   ```shell
    sudo gitlab-rails console
    ```
 
@@ -253,7 +253,7 @@ you can flip the feature flag from a Rails console.
 
 1. Enter the Rails console:
 
-   ```sh
+   ```shell
    cd /home/git/gitlab
    RAILS_ENV=production sudo -u git -H bundle exec rails console
    ```

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
@@ -178,7 +178,7 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`:
 1. Save the file and [reconfigure GitLab]s for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
 
-   ```bash
+   ```shell
    gitlab-rake gitlab:lfs:migrate
    ```
 
@@ -214,7 +214,7 @@ For source installations the settings are nested under `lfs:` and then
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
 
-   ```bash
+   ```shell
    sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production
    ```
 

doc/administration/lfs/manage_large_binaries_with_git_lfs.md

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

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

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
 
@@ -22,7 +22,7 @@ Because EXIF data may contain sensitive information (e.g. GPS location), you
 can remove EXIF data also from existing images which were uploaded before
 with the following command:
 
-```bash
+```shell
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif
 ```
 
@@ -46,13 +46,13 @@ each with a separate range of upload IDs (by setting `start_id` and `stop_id`).
 
 To run the command without dry mode and remove EXIF data from all uploads, you can use:
 
-```bash
+```shell
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[,,false,] 2>&1 | tee exif.log
 ```
 
 To run the command without dry mode on uploads with ID between 100 and 5000 and pause for 0.1 second, you can use:
 
-```bash
+```shell
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[100,5000,false,0.1] 2>&1 | tee exif.log
 ```
 

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

@@ -118,7 +118,7 @@ to validate. You can do so by specifying a range with the operation.
 This is an example of how to limit the rollout to Project IDs 50 to 100, running in
 an Omnibus GitLab installation:
 
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
 ```
 
@@ -139,7 +139,7 @@ To schedule a complete rollback, see the
 The rollback task also supports specifying a range of Project IDs. Here is an example
 of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
 
-```bash
+```shell
 sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
 ```
 

doc/administration/restart_gitlab.md

@@ -31,7 +31,7 @@ GitLab Rails application (Unicorn) as well as the other components, like:
 There may be times in the documentation where you will be asked to _restart_
 GitLab. In that case, you need to run the following command:
 
-```bash
+```shell
 sudo gitlab-ctl restart
 ```
 
@@ -51,13 +51,13 @@ ok: run: unicorn: (pid 11338) 0s
 To restart a component separately, you can append its service name to the
 `restart` command. For example, to restart **only** NGINX you would run:
 
-```bash
+```shell
 sudo gitlab-ctl restart nginx
 ```
 
 To check the status of GitLab services, run:
 
-```bash
+```shell
 sudo gitlab-ctl status
 ```
 
@@ -79,7 +79,7 @@ GitLab. Remember that this method applies only for the Omnibus packages.
 
 Reconfigure Omnibus GitLab with:
 
-```bash
+```shell
 sudo gitlab-ctl reconfigure
 ```
 
@@ -152,7 +152,7 @@ the [cloud native Helm Chart](https://docs.gitlab.com/charts/). Usually, it shou
 enough to restart a specific component separately (`gitaly`, `unicorn`,
 `workhorse`, `gitlab-shell`, etc.) by deleting all the pods related to it:
 
-```bash
+```shell
 kubectl delete pods -l release=<helm release name>,app=<component name>
 ```
 

doc/administration/server_hooks.md

@@ -111,7 +111,7 @@ declined or an error occurs during the Git hook, your script should:
 
 This hook script written in bash will generate the following message in GitLab's UI:
 
-```bash
+```shell
 #!/bin/sh
 echo "GL-HOOK-ERR: My custom error message.";
 exit 1

doc/administration/smime_signing_email.md

@@ -67,7 +67,7 @@ extensions), which contain the following in a single encrypted file:
 In order to export the required files in PEM encoding from the PKCS#12 file,
 the `openssl` command can be used:
 
-```bash
+```shell
 #-- Extract private key in PEM encoding (no password, unencrypted)
 $ openssl pkcs12 -in gitlab.p12 -nocerts -nodes -out gitlab.key
 

doc/administration/snippets/index.md

@@ -35,7 +35,7 @@ The steps to configure this setting through the Rails console are:
 
 1. Start the Rails console:
 
-   ```bash
+   ```shell
    # For Omnibus installations
    sudo gitlab-rails console
 
@@ -60,12 +60,12 @@ To retrieve the current value, start the Rails console and run:
 The process to set the snippets size limit through the Application Settings API is
 exactly the same as you would do to [update any other setting](../../api/settings.md#change-application-settings).
 
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?snippet_size_limit=52428800
 ```
 
 You can also use the API to [retrieve the current value](../../api/settings.md#get-current-application-settings).
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings
 ```

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

@@ -332,7 +332,7 @@ bind ports 9200/9300 so it can be used.
 
 The following is an example of running a docker container of Elasticsearch v7.2.0:
 
-```bash
+```shell
 docker pull docker.elastic.co/elasticsearch/elasticsearch:7.2.0
 docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.2.0
 ```

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -30,7 +30,7 @@ should and, if needed, update the script for the latest version of GitLab.
 If the script you want to run is short, you can use the Rails Runner to avoid
 entering the rails console in the first place. Here's an example of its use:
 
-```bash
+```shell
 gitlab-rails runner "RAILS_COMMAND"
 
 # Example with a 2-line script
@@ -130,19 +130,19 @@ end
 
 ### Check the GitLab version fast
 
-```bash
+```shell
 grep -m 1 gitlab /opt/gitlab/version-manifest.txt
 ```
 
 ### Debugging SSH
 
-```bash
+```shell
 GIT_SSH_COMMAND="ssh -vvv" git clone <repository>
 ```
 
 ### Debugging over HTTPS
 
-```bash
+```shell
 GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone <repository>
 ```
 
@@ -301,19 +301,19 @@ correctly named empty project using the steps below.
 
 Move the new repository to the empty repository:
 
-```bash
+```shell
 mv /var/opt/gitlab/git-data/repositories/<group>/<new-project> /var/opt/gitlab/git-data/repositories/<group>/<empty-project>
 ```
 
 Make sure the permissions are correct:
 
-```bash
+```shell
 chown -R git:git <path-to-directory>.git
 ```
 
 Clear the cache:
 
-```bash
+```shell
 sudo gitlab-rake cache:clear
 ```
 
@@ -489,7 +489,7 @@ User.active.count
 ::HistoricalData.max_historical_user_count
 ```
 
-```bash
+```shell
 # Using curl and jq (up to a max 100, see pagination docs https://docs.gitlab.com/ee/api/#pagination
 curl --silent --header "Private-Token: ********************" "https://gitlab.example.com/api/v4/users?per_page=100&active" | jq --compact-output '.[] | [.id,.name,.username]'
 ```
@@ -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>
 ```
 
@@ -1034,7 +1034,7 @@ This script will go through all the encrypted variables and count how many are n
 to be decrypted. Might be helpful to run on multiple nodes to see which `gitlab-secrets.json`
 file is most up to date:
 
-```bash
+```shell
 wget -O /tmp/bad-decrypt.rb https://gitlab.com/snippets/1730735/raw
 gitlab-rails runner /tmp/bad-decrypt.rb
 ```
@@ -1075,7 +1075,7 @@ two-factor authentication.
 This script will search for all encrypted tokens that are causing decryption errors,
 and update or reset as needed:
 
-```bash
+```shell
 wget -O /tmp/encrypted-tokens.rb https://gitlab.com/snippets/1876342/raw
 gitlab-rails runner /tmp/encrypted-tokens.rb
 ```

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -20,13 +20,13 @@ and they will assist you with any issues you are having.
 - How to authorize to your GCP project (can be especially useful if you have projects
   under different GCP accounts):
 
-  ```bash
+  ```shell
   gcloud auth login
   ```
 
 - How to access Kubernetes dashboard:
 
-  ```bash
+  ```shell
   # for minikube:
   minikube dashboard —url
   # for non-local installations if access via Kubectl is configured:
@@ -42,7 +42,7 @@ and they will assist you with any issues you are having.
 
 - How to copy a file from local machine to a pod:
 
-  ```bash
+  ```shell
   kubectl cp file-name pod-name:./destination-path
   ```
 
@@ -51,19 +51,19 @@ and they will assist you with any issues you are having.
   - Check logs via Kubernetes dashboard.
   - Check logs via Kubectl:
 
-    ```bash
+    ```shell
     kubectl logs <unicorn pod> -c dependencies
     ```
 
 - How to tail all Kubernetes cluster events in real time:
 
-  ```bash
+  ```shell
   kubectl get events -w --all-namespaces
   ```
 
 - How to get logs of the previously terminated pod instance:
 
-  ```bash
+  ```shell
   kubectl logs <pod-name> --previous
   ```
 
@@ -79,13 +79,13 @@ and they will assist you with any issues you are having.
 
 - Tailing logs of a separate pod. An example for a Unicorn pod:
 
-  ```bash
+  ```shell
   kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn
   ```
 
 - Tail and follow all pods that share a label (in this case, `unicorn`):
 
-  ```bash
+  ```shell
   # all containers in the unicorn pods
   kubectl logs -f -l app=unicorn --all-containers=true --max-log-requests=50
 
@@ -96,21 +96,21 @@ and they will assist you with any issues you are having.
 - One can stream logs from all containers at once, similar to the Omnibus
   command `gitlab-ctl tail`:
 
-  ```bash
+  ```shell
   kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100
   ```
 
 - Check all events in the `gitlab` namespace (the namespace name can be different if you
   specified a different one when deploying the Helm chart):
 
-  ```bash
+  ```shell
   kubectl get events -w --namespace=gitlab
   ```
 
 - Most of the useful GitLab tools (console, rake tasks, etc) are found in the task-runner
   pod. You may enter it and run commands inside or run them from the outside:
 
-  ```bash
+  ```shell
   # find the pod
   kubectl get pods | grep task-runner
 
@@ -145,7 +145,7 @@ and they will assist you with any issues you are having.
 
 - How to get your initial admin password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>:
 
-  ```bash
+  ```shell
   # find the name of the secret containing the password
   kubectl get secrets | grep initial-root
   # decode it
@@ -154,19 +154,19 @@ and they will assist you with any issues you are having.
 
 - How to connect to a GitLab Postgres database:
 
-  ```bash
+  ```shell
   kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole -p
   ```
   
 - How to get info about Helm installation status:
 
-  ```bash
+  ```shell
   helm status name-of-installation
   ```
 
 - How to update GitLab installed using Helm Chart:
 
-  ```bash
+  ```shell
   helm repo upgrade
 
   # get current values and redirect them to yaml file (analogue of gitlab.rb values)
@@ -185,7 +185,7 @@ and they will assist you with any issues you are having.
   - Modify the `gitlab.yaml` file.
   - Run the following command to apply changes:
 
-    ```bash
+    ```shell
     helm upgrade <release name> <chart path> -f gitlab.yaml
     ```
 
@@ -197,20 +197,20 @@ to those documents for details.
 
 - Install Kubectl via Homebrew:
 
-  ```bash
+  ```shell
   brew install kubernetes-cli
   ```
 
 - Install Minikube via Homebrew:
 
-  ```bash
+  ```shell
   brew cask install minikube
   ```
 
 - Start Minikube and configure it. If Minikube cannot start, try running `minikube delete && minikube start`
   and repeat the steps:
 
-  ```bash
+  ```shell
   minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
   minikube addons enable ingress
   minikube addons enable kube-dns
@@ -218,7 +218,7 @@ to those documents for details.
 
 - Install Helm via Homebrew and initialize it:
 
-  ```bash
+  ```shell
   brew install kubernetes-helm
   helm init --service-account tiller
   ```
@@ -231,7 +231,7 @@ to those documents for details.
 
 - Install the GitLab Helm Chart:
 
-  ```bash
+  ```shell
   helm repo add gitlab https://charts.gitlab.io
   helm install --name gitlab -f <path-to-yaml-file> gitlab/gitlab
   ```

doc/administration/troubleshooting/linux_cheat_sheet.md

@@ -23,7 +23,7 @@ on. Contributions are welcome to help add them.
 
 ### Distro Information
 
-```bash
+```shell
 # Debian/Ubuntu
 uname -a
 lsb_release -a
@@ -38,14 +38,14 @@ cat /etc/os-release
 
 ### Shut down or Reboot
 
-```bash
+```shell
 shutdown -h now
 reboot
 ```
 
 ### Permissions
 
-```bash
+```shell
 # change the user:group ownership of a file/dir
 chown root:git <file_or_dir>
 
@@ -55,7 +55,7 @@ chmod u+x <file>
 
 ### Files & Dirs
 
-```bash
+```shell
 # create a new directory and all subdirectories
 mkdir -p dir/dir2/dir3
 
@@ -71,7 +71,7 @@ sed -i 's/original-text/new-text/g' <filename>
 
 ### See all set environment variables
 
-```bash
+```shell
 env
 ```
 
@@ -79,7 +79,7 @@ env
 
 ### File names
 
-```bash
+```shell
 # search for a file in a filesystem
 find . -name 'filename.rb' -print
 
@@ -95,7 +95,7 @@ history
 
 ### File contents
 
-```bash
+```shell
 # -B/A = show 2 lines before/after search_term
 grep -B 2 -A 2 search_term <filename>
 
@@ -114,7 +114,7 @@ fgrep -R string_pattern <filename or directory>
 
 ### CLI
 
-```bash
+```shell
 # View command history
 history
 
@@ -132,7 +132,7 @@ sudo !!
 
 ### Memory, Disk, & CPU usage
 
-```bash
+```shell
 # disk space info.  The '-h' gives the data in human-readable values
 df -h
 
@@ -157,7 +157,7 @@ top -o %CPU
 
 ### Strace
 
-```bash
+```shell
 # strace a process
 strace -tt -T -f -y -s 1024 -p <pid>
 
@@ -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
@@ -274,7 +274,7 @@ small differences should not be considered significant.
 
 ### Ports
 
-```bash
+```shell
 # Find the programs that are listening on ports
 netstat -plnt
 ss -plnt
@@ -283,7 +283,7 @@ lsof -i -P | grep <port>
 
 ### Internet/DNS
 
-```bash
+```shell
 # Show domain IP address
 dig +short example.com
 nslookup example.com
@@ -302,7 +302,7 @@ curl --head --location https://example.com
 
 ## Package Management
 
-```bash
+```shell
 # Debian/Ubuntu
 
 # List packages
@@ -332,7 +332,7 @@ rpm -qa | grep <package>
 
 ## Logs
 
-```bash
+```shell
 # Print last lines in log file where 'n'
 # is the number of lines to print
 tail -n /path/to/log/file

doc/administration/troubleshooting/ssl.md

@@ -83,13 +83,13 @@ To fix this problem:
 
 If your GitLab instance is using a self-signed certificate, or the certificate is signed by an internal certificate authority (CA), you might run into the following errors when attempting to perform Git operations:
 
-```bash
+```shell
 $ git clone https://gitlab.domain.tld/group/project.git
 Cloning into 'project'...
 fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate
 ```
 
-```bash
+```shell
 $ git clone https://gitlab.domain.tld/group/project.git
 Cloning into 'project'...
 fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
@@ -107,6 +107,6 @@ To fix this problem:
 
   - Disable SSL verification in your Git client. Note that this intended as a temporary measure as it could be considered a **security risk**.
 
-    ```bash
+    ```shell
     git config --global http.sslVerify false
     ```

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

@@ -335,7 +335,7 @@ resources you can pass the following parameters:
 
 In the example below, we list 50 [namespaces](namespaces.md) per page.
 
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/namespaces?per_page=50"
 ```
 
@@ -349,7 +349,7 @@ In the cURL example below, we limit the output to 3 items per page (`per_page=3`
 and we request the second page (`page=2`) of [comments](notes.md) of the issue
 with ID `8` which belongs to the project with ID `8`:
 
-```bash
+```shell
 curl --head --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/8/issues/8/notes?per_page=3&page=2
 ```
 
@@ -409,7 +409,7 @@ This method is controlled by the following parameters:
 
 In the example below, we list 50 [projects](projects.md) per page, ordered by `id` ascending.
 
-```bash
+```shell
 curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc"
 ```
 
@@ -472,7 +472,7 @@ We can call the API with `array` and `hash` types parameters as shown below:
 
 `import_sources` is a parameter of type `array`:
 
-```bash
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
 -d "import_sources[]=github" \
 -d "import_sources[]=bitbucket" \
@@ -483,7 +483,7 @@ https://gitlab.example.com/api/v4/some_endpoint
 
 `override_params` is a parameter of type `hash`:
 
-```bash
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
 --form "namespace=email" \
 --form "path=impapi" \
@@ -497,7 +497,7 @@ https://gitlab.example.com/api/v4/projects/import
 
 `variables` is a parameter of type `array` containing hash key/value pairs `[{ 'key' => 'UPLOAD_TO_S3', 'value' => 'true' }]`:
 
-```bash
+```shell
 curl --globoff --request POST --header "PRIVATE-TOKEN: ********************" \
 "https://gitlab.example.com/api/v4/projects/169/pipeline?ref=master&variables[][key]=VAR1&variables[][value]=hello&variables[][key]=VAR2&variables[][value]=world"
 

doc/api/access_requests.md

@@ -29,7 +29,7 @@ GET /projects/:id/access_requests
 
 Example request:
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests
 ```
@@ -72,7 +72,7 @@ POST /projects/:id/access_requests
 
 Example request:
 
-```bash
+```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests
 ```
@@ -107,7 +107,7 @@ PUT /projects/:id/access_requests/:user_id/approve
 
 Example request:
 
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests/:user_id/approve?access_level=20
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests/:user_id/approve?access_level=20
 ```
@@ -141,7 +141,7 @@ DELETE /projects/:id/access_requests/:user_id
 
 Example request:
 
-```bash
+```shell
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests/:user_id
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests/:user_id
 ```

doc/api/appearance.md

@@ -13,7 +13,7 @@ List the current appearance configuration of the GitLab instance.
 GET /application/appearance
 ```
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/appearance
 ```
 
@@ -57,7 +57,7 @@ PUT /application/appearance
 | `message_font_color`              | string  | no       | Font color for the system header / footer bar
 | `email_header_and_footer_enabled` | boolean | no       | Add header and footer to all outgoing emails if enabled
 
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/appearance?email_header_and_footer_enabled=true&header_message=test
 ```
 

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

@@ -24,7 +24,7 @@ are paginated.
 
 Read more on [pagination](README.md#pagination).
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/audit_events
 ```
 
@@ -91,7 +91,7 @@ Example response:
 GET /audit_events/:id
 ```
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/audit_events/1
 ```
 
@@ -141,7 +141,7 @@ are paginated.
 
 Read more on [pagination](README.md#pagination).
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/groups/60/audit_events
 ```
 
@@ -197,7 +197,7 @@ GET /groups/:id/audit_events/:audit_event_id
 | `id` | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) |
 | `audit_event_id` | integer | yes | ID of the audit event |
 
-```bash
+```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/groups/60/audit_events/2
 ```