Fix spacing of code blocks

Code blocks should not be spaced 4 times, as this will
prevent the code from being colored. They should
also be spaced the same as the lists they are a part
of, to make reading easier.

doc/administration/database_load_balancing.md

@@ -74,9 +74,9 @@ the following. This will balance the load between `host1.example.com` and
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['db_load_balancing'] = { 'hosts' => ['host1.example.com', 'host2.example.com'] }
-    ```
+   ```ruby
+   gitlab_rails['db_load_balancing'] = { 'hosts' => ['host1.example.com', 'host2.example.com'] }
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -86,16 +86,16 @@ the following. This will balance the load between `host1.example.com` and
 
 1. Edit `/home/git/gitlab/config/database.yml` and add or amend the following lines:
 
-    ```yaml
-    production:
-      username: gitlab
-      database: gitlab
-      encoding: unicode
-      load_balancing:
-        hosts:
-          - host1.example.com
-          - host2.example.com
-    ```
+   ```yaml
+   production:
+     username: gitlab
+     database: gitlab
+     encoding: unicode
+     load_balancing:
+       hosts:
+         - host1.example.com
+         - host2.example.com
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 

doc/administration/incoming_email.md

@@ -102,16 +102,16 @@ for a real-world example of this exploit.
 
 1. Reconfigure GitLab for the changes to take effect:
 
-    ```sh
-    sudo gitlab-ctl reconfigure
-    sudo gitlab-ctl restart
-    ```
+   ```sh
+   sudo gitlab-ctl reconfigure
+   sudo gitlab-ctl restart
+   ```
 
 1. Verify that everything is configured correctly:
 
-    ```sh
-    sudo gitlab-rake gitlab:incoming_email:check
-    ```
+   ```sh
+   sudo gitlab-rake gitlab:incoming_email:check
+   ```
 
 Reply by email should now be working.
 
@@ -119,31 +119,31 @@ Reply by email should now be working.
 
 1. Go to the GitLab installation directory:
 
-    ```sh
-    cd /home/git/gitlab
-    ```
+   ```sh
+   cd /home/git/gitlab
+   ```
 
 1. Find the `incoming_email` section in `config/gitlab.yml`, enable the feature
   and fill in the details for your specific IMAP server and email account (see [examples](#config-examples) below).
 
 1. Enable `mail_room` in the init script at `/etc/default/gitlab`:
 
-    ```sh
-    sudo mkdir -p /etc/default
-    echo 'mail_room_enabled=true' | sudo tee -a /etc/default/gitlab
-    ```
+   ```sh
+   sudo mkdir -p /etc/default
+   echo 'mail_room_enabled=true' | sudo tee -a /etc/default/gitlab
+   ```
 
 1. Restart GitLab:
 
-    ```sh
-    sudo service gitlab restart
-    ```
+   ```sh
+   sudo service gitlab restart
+   ```
 
 1. Verify that everything is configured correctly:
 
-    ```sh
-    sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production
-    ```
+   ```sh
+   sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production
+   ```
 
 Reply by email should now be working.
 

doc/administration/issue_closing_pattern.md

@@ -27,9 +27,10 @@ Because Rubular doesn't understand `%{issue_ref}`, you can replace this by
 1. Change the value of `gitlab_rails['gitlab_issue_closing_pattern']` to a regular
    expression of your liking:
 
-    ```ruby
-    gitlab_rails['gitlab_issue_closing_pattern'] = "\b((?:[Cc]los(?:e[sd]|ing)|\b[Ff]ix(?:e[sd]|ing)?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?))+)"
-    ```
+   ```ruby
+   gitlab_rails['gitlab_issue_closing_pattern'] = "\b((?:[Cc]los(?:e[sd]|ing)|\b[Ff]ix(?:e[sd]|ing)?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?))+)"
+   ```
+
 1. [Reconfigure] GitLab for the changes to take effect.
 
 **For installations from source**
@@ -37,9 +38,9 @@ Because Rubular doesn't understand `%{issue_ref}`, you can replace this by
 1. Open `gitlab.yml` with your editor.
 1. Change the value of `issue_closing_pattern`:
 
-    ```yaml
-    issue_closing_pattern: "\b((?:[Cc]los(?:e[sd]|ing)|\b[Ff]ix(?:e[sd]|ing)?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?))+)"
-    ```
+   ```yaml
+   issue_closing_pattern: "\b((?:[Cc]los(?:e[sd]|ing)|\b[Ff]ix(?:e[sd]|ing)?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?))+)"
+   ```
 
 1. [Restart] GitLab for the changes to take effect.
 

doc/administration/job_artifacts.md

 # Jobs artifacts administration
 
-> **Notes:**
->
 > - Introduced in GitLab 8.2 and GitLab Runner 0.7.0.
 > - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format changed to `ZIP`.
 > - Starting with GitLab 8.17, builds are renamed to jobs.
@@ -21,9 +19,9 @@ To disable artifacts site-wide, follow the steps below.
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['artifacts_enabled'] = false
-    ```
+   ```ruby
+   gitlab_rails['artifacts_enabled'] = false
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -33,10 +31,10 @@ To disable artifacts site-wide, follow the steps below.
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
 
-    ```yaml
-    artifacts:
-      enabled: false
-    ```
+   ```yaml
+   artifacts:
+     enabled: false
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 
@@ -61,9 +59,9 @@ _The artifacts are stored by default in
 1. To change the storage path for example to `/mnt/storage/artifacts`, edit
    `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['artifacts_path'] = "/mnt/storage/artifacts"
-    ```
+   ```ruby
+   gitlab_rails['artifacts_path'] = "/mnt/storage/artifacts"
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -77,18 +75,16 @@ _The artifacts are stored by default in
 1. To change the storage path for example to `/mnt/storage/artifacts`, edit
    `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
 
-    ```yaml
-    artifacts:
-      enabled: true
-      path: /mnt/storage/artifacts
-    ```
+   ```yaml
+   artifacts:
+     enabled: true
+     path: /mnt/storage/artifacts
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 
 ### Using object storage
 
-> **Notes:**
->
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1762) in
 >   [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
 > - Since version 9.5, artifacts are [browsable](../user/project/pipelines/job_artifacts.md#browsing-artifacts),
@@ -141,35 +137,35 @@ _The artifacts are stored by default in
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
    the values you want:
 
-    ```ruby
-    gitlab_rails['artifacts_enabled'] = true
-    gitlab_rails['artifacts_object_store_enabled'] = true
-    gitlab_rails['artifacts_object_store_remote_directory'] = "artifacts"
-    gitlab_rails['artifacts_object_store_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
-      'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
-    }
-    ```
-
-    NOTE: For GitLab 9.4+, if you are using AWS IAM profiles, be sure to omit the
-    AWS access key and secret access key/value pairs. For example:
-
-    ```ruby
-    gitlab_rails['artifacts_object_store_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'use_iam_profile' => true
-    }
-    ```
+   ```ruby
+   gitlab_rails['artifacts_enabled'] = true
+   gitlab_rails['artifacts_object_store_enabled'] = true
+   gitlab_rails['artifacts_object_store_remote_directory'] = "artifacts"
+   gitlab_rails['artifacts_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
+     'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
+   }
+   ```
+
+   NOTE: For GitLab 9.4+, if you are using AWS IAM profiles, be sure to omit the
+   AWS access key and secret access key/value pairs. For example:
+
+   ```ruby
+   gitlab_rails['artifacts_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'use_iam_profile' => true
+   }
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
 
-    ```bash
-    gitlab-rake gitlab:artifacts:migrate
-    ```
+   ```bash
+   gitlab-rake gitlab:artifacts:migrate
+   ```
 
 ---
 
@@ -181,25 +177,25 @@ _The artifacts are stored by default in
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    artifacts:
-      enabled: true
-      object_store:
-        enabled: true
-        remote_directory: "artifacts" # The bucket name
-        connection:
-          provider: AWS # Only AWS supported at the moment
-          aws_access_key_id: AWS_ACCESS_KEY_ID
-          aws_secret_access_key: AWS_SECRET_ACCESS_KEY
-          region: eu-central-1
-    ```
+   ```yaml
+   artifacts:
+     enabled: true
+     object_store:
+       enabled: true
+       remote_directory: "artifacts" # The bucket name
+       connection:
+         provider: AWS # Only AWS supported at the moment
+         aws_access_key_id: AWS_ACCESS_KEY_ID
+         aws_secret_access_key: AWS_SECRET_ACCESS_KEY
+         region: eu-central-1
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
 
-    ```bash
-    sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
-    ```
+   ```bash
+   sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
+   ```
 
 ## Expiring artifacts
 
@@ -217,9 +213,9 @@ steps below.
 
 1. Edit `/etc/gitlab/gitlab.rb` and comment out or add the following line
 
-    ```ruby
-    gitlab_rails['expire_build_artifacts_worker_cron'] = "50 * * * *"
-    ```
+   ```ruby
+   gitlab_rails['expire_build_artifacts_worker_cron'] = "50 * * * *"
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -230,10 +226,10 @@ steps below.
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    expire_build_artifacts_worker:
-      cron: "50 * * * *"
-    ```
+   ```yaml
+   expire_build_artifacts_worker:
+     cron: "50 * * * *"
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 
@@ -250,15 +246,15 @@ you can flip the feature flag from a Rails console.
 
 1. Enter the Rails console:
 
-    ```sh
-    sudo gitlab-rails console
-    ```
+   ```sh
+   sudo gitlab-rails console
+   ```
 
 1. Flip the switch and disable it:
 
-    ```ruby
-    Feature.enable('ci_disable_validates_dependencies')
-    ```
+   ```ruby
+   Feature.enable('ci_disable_validates_dependencies')
+   ```
 
 ---
 
@@ -266,16 +262,16 @@ you can flip the feature flag from a Rails console.
 
 1. Enter the Rails console:
 
-    ```sh
-    cd /home/git/gitlab
-    RAILS_ENV=production sudo -u git -H bundle exec rails console
-    ```
+   ```sh
+   cd /home/git/gitlab
+   RAILS_ENV=production sudo -u git -H bundle exec rails console
+   ```
 
 1. Flip the switch and disable it:
 
-    ```ruby
-    Feature.enable('ci_disable_validates_dependencies')
-    ```
+   ```ruby
+   Feature.enable('ci_disable_validates_dependencies')
+   ```
 
 ## Set the maximum file size of the artifacts
 

doc/administration/job_traces.md

@@ -25,11 +25,11 @@ To change the location where the job logs will be stored, follow the steps below
 
 **In Omnibus installations:**
 
-1.  Edit `/etc/gitlab/gitlab.rb` and add or amend the following line:
+1. Edit `/etc/gitlab/gitlab.rb` and add or amend the following line:
 
-    ```
-    gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
-    ```
+   ```ruby
+   gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -39,12 +39,12 @@ To change the location where the job logs will be stored, follow the steps below
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
 
-    ```yaml
-    gitlab_ci:
-      # The location where build traces are stored (default: builds/).
-      # Relative paths are relative to Rails.root.
-      builds_path: path/to/builds/
-    ```
+   ```yaml
+   gitlab_ci:
+     # The location where build traces are stored (default: builds/).
+     # Relative paths are relative to Rails.root.
+     builds_path: path/to/builds/
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 
@@ -67,24 +67,24 @@ To archive those legacy job traces, please follow the instruction below.
 
 1. Execute the following command
 
-    ```bash
-    gitlab-rake gitlab:traces:archive
-    ```
+   ```bash
+   gitlab-rake gitlab:traces:archive
+   ```
 
-    After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes)
-    for migrating job trace files from local storage to object storage.
-    It could take time to complete the all migration jobs. You can check the progress by the following command
+   After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes)
+   for migrating job trace files from local storage to object storage.
+   It could take time to complete the all migration jobs. You can check the progress by the following command
 
-    ```bash
-    sudo gitlab-rails console
-    ```
+   ```bash
+   sudo gitlab-rails console
+   ```
 
-    ```bash
-    [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace']
-    => 100
-    ```
+   ```bash
+   [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace']
+   => 100
+   ```
 
-    If the count becomes zero, the archiving processes are done
+   If the count becomes zero, the archiving processes are done
 
 ## How to migrate archived job traces to object storage
 

doc/administration/merge_request_diffs.md

@@ -21,18 +21,18 @@ To enable external storage of merge request diffs, follow the instructions below
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['external_diffs_enabled'] = true
-    ```
+   ```ruby
+   gitlab_rails['external_diffs_enabled'] = true
+   ```
 
 1. _The external diffs will be stored in in
    `/var/opt/gitlab/gitlab-rails/shared/external-diffs`._ To change the path,
    for example, to `/mnt/storage/external-diffs`, edit `/etc/gitlab/gitlab.rb`
    and add the following line:
 
-    ```ruby
-    gitlab_rails['external_diffs_storage_path'] = "/mnt/storage/external-diffs"
-    ```
+   ```ruby
+   gitlab_rails['external_diffs_storage_path'] = "/mnt/storage/external-diffs"
+   ```
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -41,21 +41,21 @@ To enable external storage of merge request diffs, follow the instructions below
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    external_diffs:
-      enabled: true
-    ```
+   ```yaml
+   external_diffs:
+     enabled: true
+   ```
 
 1. _The external diffs will be stored in
    `/home/git/gitlab/shared/external-diffs`._ To change the path, for example,
    to `/mnt/storage/external-diffs`, edit `/home/git/gitlab/config/gitlab.yml`
    and add or amend the following lines:
 
-    ```yaml
-    external_diffs:
-      enabled: true
-      storage_path: /mnt/storage/external-diffs
-    ```
+   ```yaml
+   external_diffs:
+     enabled: true
+     storage_path: /mnt/storage/external-diffs
+   ```
 
 1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
@@ -101,28 +101,28 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
    the values you want:
 
-    ```ruby
-    gitlab_rails['external_diffs_enabled'] = true
-    gitlab_rails['external_diffs_object_store_enabled'] = true
-    gitlab_rails['external_diffs_object_store_remote_directory'] = "external-diffs"
-    gitlab_rails['external_diffs_object_store_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
-      'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
-    }
-    ```
-
-    Note that, if you are using AWS IAM profiles, be sure to omit the
-    AWS access key and secret access key/value pairs. For example:
-
-    ```ruby
-    gitlab_rails['external_diffs_object_store_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'use_iam_profile' => true
-    }
-    ```
+   ```ruby
+   gitlab_rails['external_diffs_enabled'] = true
+   gitlab_rails['external_diffs_object_store_enabled'] = true
+   gitlab_rails['external_diffs_object_store_remote_directory'] = "external-diffs"
+   gitlab_rails['external_diffs_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
+     'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
+   }
+   ```
+
+   Note that, if you are using AWS IAM profiles, be sure to omit the
+   AWS access key and secret access key/value pairs. For example:
+
+   ```ruby
+   gitlab_rails['external_diffs_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'use_iam_profile' => true
+   }
+   ```
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -131,18 +131,18 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    external_diffs:
-      enabled: true
-      object_store:
-        enabled: true
-        remote_directory: "external-diffs" # The bucket name
-        connection:
-          provider: AWS # Only AWS supported at the moment
-          aws_access_key_id: AWS_ACCESS_KEY_ID
-          aws_secret_access_key: AWS_SECRET_ACCESS_KEY
-          region: eu-central-1
-    ```
+   ```yaml
+   external_diffs:
+     enabled: true
+     object_store:
+       enabled: true
+       remote_directory: "external-diffs" # The bucket name
+       connection:
+         provider: AWS # Only AWS supported at the moment
+         aws_access_key_id: AWS_ACCESS_KEY_ID
+         aws_secret_access_key: AWS_SECRET_ACCESS_KEY
+         region: eu-central-1
+   ```
 
 1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
@@ -157,11 +157,11 @@ To enable this feature, perform the following steps:
 
 **In Omnibus installations:**
 
-1.  Edit `/etc/gitlab/gitlab.rb` and add the following line:
+1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['external_diffs_when'] = 'outdated'
-    ```
+   ```ruby
+   gitlab_rails['external_diffs_when'] = 'outdated'
+   ```
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -170,11 +170,11 @@ To enable this feature, perform the following steps:
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    external_diffs:
-      enabled: true
-      when: outdated
-    ```
+   ```yaml
+   external_diffs:
+     enabled: true
+     when: outdated
+   ```
 
 1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 

doc/administration/packages.md

@@ -28,9 +28,9 @@ To enable the Packages feature:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['packages_enabled'] = true
-    ```
+   ```ruby
+   gitlab_rails['packages_enabled'] = true
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -39,10 +39,11 @@ To enable the Packages feature:
 1. After the installation is complete, you will have to configure the `packages`
    section in `config/gitlab.yml`. Set to `true` to enable it:
 
-      ```yaml
-      packages:
-        enabled: true
-      ```
+   ```yaml
+   packages:
+     enabled: true
+   ```
+
 1. [Restart GitLab] for the changes to take effect.
 
 ## Changing the storage path
@@ -61,9 +62,9 @@ To change the local storage path:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['packages_storage_path'] = "/mnt/packages"
-    ```
+   ```ruby
+   gitlab_rails['packages_storage_path'] = "/mnt/packages"
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -71,11 +72,12 @@ To change the local storage path:
 
 1. Edit the `packages` section in `config/gitlab.yml`:
 
-      ```yaml
-      packages:
-        enabled: true
-        storage_path: shared/packages
-      ```
+   ```yaml
+   packages:
+     enabled: true
+     storage_path: shared/packages
+   ```
+
 1. [Restart GitLab] for the changes to take effect.
 
 ### Using object storage
@@ -88,31 +90,31 @@ upload packages:
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines (uncomment where
    necessary):
 
-    ```ruby
-    gitlab_rails['packages_enabled'] = true
-    gitlab_rails['packages_storage_path'] = "/var/opt/gitlab/gitlab-rails/shared/packages"
-    gitlab_rails['packages_object_store_enabled'] = true
-    gitlab_rails['packages_object_store_remote_directory'] = "packages" # The bucket name.
-    gitlab_rails['packages_object_store_direct_upload'] = false         # Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
-    gitlab_rails['packages_object_store_background_upload'] = true      # Temporary option to limit automatic upload (Default: true).
-    gitlab_rails['packages_object_store_proxy_download'] = false        # Passthrough all downloads via GitLab instead of using Redirects to Object Storage.
-    gitlab_rails['packages_object_store_connection'] = {
-      ##
-      ## If the provider is AWS S3, uncomment the following
-      ##
-      #'provider' => 'AWS',
-      #'region' => 'eu-west-1',
-      #'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
-      #'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY',
-      ##
-      ## If the provider is other than AWS (an S3-compatible one), uncomment the following
-      ##
-      #'host' => 's3.amazonaws.com',
-      #'aws_signature_version' => 4             # For creation of signed URLs. Set to 2 if provider does not support v4.
-      #'endpoint' => 'https://s3.amazonaws.com' # Useful for S3-compliant services such as DigitalOcean Spaces.
-      #'path_style' => false                    # If true, use 'host/bucket_name/object' instead of 'bucket_name.host/object'.
-    }
-    ```
+   ```ruby
+   gitlab_rails['packages_enabled'] = true
+   gitlab_rails['packages_storage_path'] = "/var/opt/gitlab/gitlab-rails/shared/packages"
+   gitlab_rails['packages_object_store_enabled'] = true
+   gitlab_rails['packages_object_store_remote_directory'] = "packages" # The bucket name.
+   gitlab_rails['packages_object_store_direct_upload'] = false         # Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
+   gitlab_rails['packages_object_store_background_upload'] = true      # Temporary option to limit automatic upload (Default: true).
+   gitlab_rails['packages_object_store_proxy_download'] = false        # Passthrough all downloads via GitLab instead of using Redirects to Object Storage.
+   gitlab_rails['packages_object_store_connection'] = {
+     ##
+     ## If the provider is AWS S3, uncomment the following
+     ##
+     #'provider' => 'AWS',
+     #'region' => 'eu-west-1',
+     #'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
+     #'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY',
+     ##
+     ## If the provider is other than AWS (an S3-compatible one), uncomment the following
+     ##
+     #'host' => 's3.amazonaws.com',
+     #'aws_signature_version' => 4             # For creation of signed URLs. Set to 2 if provider does not support v4.
+     #'endpoint' => 'https://s3.amazonaws.com' # Useful for S3-compliant services such as DigitalOcean Spaces.
+     #'path_style' => false                    # If true, use 'host/bucket_name/object' instead of 'bucket_name.host/object'.
+   }
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -120,35 +122,35 @@ upload packages:
 
 1. Edit the `packages` section in `config/gitlab.yml` (uncomment where necessary):
 
-    ```yaml
-      packages:
-        enabled: true
-        ##
-        ## The location where build packages are stored (default: shared/packages).
-        ##
-        #storage_path: shared/packages
-        object_store:
-          enabled: false
-          remote_directory: packages # The bucket name.
-          #direct_upload: false      # Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
-          #background_upload: true   # Temporary option to limit automatic upload (Default: true).
-          #proxy_download: false     # Passthrough all downloads via GitLab instead of using Redirects to Object Storage.
-          connection:
-            ##
-            ## If the provider is AWS S3, uncomment the following
-            ##
-            #provider: AWS
-            #region: us-east-1
-            #aws_access_key_id: AWS_ACCESS_KEY_ID
-            #aws_secret_access_key: AWS_SECRET_ACCESS_KEY
-            ##
-            ## If the provider is other than AWS (an S3-compatible one), uncomment the following
-            ##
-            #host: 's3.amazonaws.com'             # default: s3.amazonaws.com.
-            #aws_signature_version: 4             # For creation of signed URLs. Set to 2 if provider does not support v4.
-            #endpoint: 'https://s3.amazonaws.com' # Useful for S3-compliant services such as DigitalOcean Spaces.
-            #path_style: false                    # If true, use 'host/bucket_name/object' instead of 'bucket_name.host/object'.
-    ```
+   ```yaml
+     packages:
+       enabled: true
+       ##
+       ## The location where build packages are stored (default: shared/packages).
+       ##
+       #storage_path: shared/packages
+       object_store:
+         enabled: false
+         remote_directory: packages # The bucket name.
+         #direct_upload: false      # Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
+         #background_upload: true   # Temporary option to limit automatic upload (Default: true).
+         #proxy_download: false     # Passthrough all downloads via GitLab instead of using Redirects to Object Storage.
+         connection:
+           ##
+           ## If the provider is AWS S3, uncomment the following
+           ##
+           #provider: AWS
+           #region: us-east-1
+           #aws_access_key_id: AWS_ACCESS_KEY_ID
+           #aws_secret_access_key: AWS_SECRET_ACCESS_KEY
+           ##
+           ## If the provider is other than AWS (an S3-compatible one), uncomment the following
+           ##
+           #host: 's3.amazonaws.com'             # default: s3.amazonaws.com.
+           #aws_signature_version: 4             # For creation of signed URLs. Set to 2 if provider does not support v4.
+           #endpoint: 'https://s3.amazonaws.com' # Useful for S3-compliant services such as DigitalOcean Spaces.
+           #path_style: false                    # If true, use 'host/bucket_name/object' instead of 'bucket_name.host/object'.
+   ```
 
 1. [Restart GitLab] for the changes to take effect.
 

doc/administration/pseudonymizer.md

@@ -31,27 +31,27 @@ To configure the pseudonymizer, you need to:
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
    the values you want:
 
-    ```ruby
-    gitlab_rails['pseudonymizer_manifest'] = 'config/pseudonymizer.yml'
-    gitlab_rails['pseudonymizer_upload_remote_directory'] = 'gitlab-elt' # bucket name
-    gitlab_rails['pseudonymizer_upload_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
-      'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
-    }
-    ```
-
-    NOTE: **Note:**
-    If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
-
-    ```ruby
-    gitlab_rails['pseudonymizer_upload_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'use_iam_profile' => true
-    }
-    ```
+   ```ruby
+   gitlab_rails['pseudonymizer_manifest'] = 'config/pseudonymizer.yml'
+   gitlab_rails['pseudonymizer_upload_remote_directory'] = 'gitlab-elt' # bucket name
+   gitlab_rails['pseudonymizer_upload_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
+     'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
+   }
+   ```
+
+   NOTE: **Note:**
+   If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
+
+   ```ruby
+   gitlab_rails['pseudonymizer_upload_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'use_iam_profile' => true
+   }
+   ```
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
@@ -63,17 +63,17 @@ To configure the pseudonymizer, you need to:
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    pseudonymizer:
-	  manifest: config/pseudonymizer.yml
-	  upload:
-        remote_directory: 'gitlab-elt' # bucket name
-        connection:
-          provider: AWS
-          aws_access_key_id: AWS_ACCESS_KEY_ID
-          aws_secret_access_key: AWS_SECRET_ACCESS_KEY
-          region: eu-central-1
-    ```
+   ```yaml
+   pseudonymizer:
+   manifest: config/pseudonymizer.yml
+   upload:
+       remote_directory: 'gitlab-elt' # bucket name
+       connection:
+         provider: AWS
+         aws_access_key_id: AWS_ACCESS_KEY_ID
+         aws_secret_access_key: AWS_SECRET_ACCESS_KEY
+         region: eu-central-1
+   ```
 
 1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source)
    for the changes to take effect.

doc/administration/repository_storage_paths.md

@@ -68,18 +68,18 @@ NOTE: **Note:** This example uses NFS and CephFS. We do not recommend using EFS
 
 1. Edit `gitlab.yml` and add the storage paths:
 
-    ```yaml
-    repositories:
-      # Paths where repositories can be stored. Give the canonicalized absolute pathname.
-      # NOTE: REPOS PATHS MUST NOT CONTAIN ANY SYMLINK!!!
-      storages: # You must have at least a 'default' storage path.
-        default:
-          path: /home/git/repositories
-        nfs:
-          path: /mnt/nfs/repositories
-        cephfs:
-          path: /mnt/cephfs/repositories
-    ```
+   ```yaml
+   repositories:
+     # Paths where repositories can be stored. Give the canonicalized absolute pathname.
+     # NOTE: REPOS PATHS MUST NOT CONTAIN ANY SYMLINK!!!
+     storages: # You must have at least a 'default' storage path.
+       default:
+         path: /home/git/repositories
+       nfs:
+         path: /mnt/nfs/repositories
+       cephfs:
+         path: /mnt/cephfs/repositories
+   ```
 
 1. [Restart GitLab][restart-gitlab] for the changes to take effect.
 
@@ -97,16 +97,16 @@ working, you can remove the `repos_path` line.
 1. Edit `/etc/gitlab/gitlab.rb` by appending the rest of the paths to the
    default one:
 
-    ```ruby
-    git_data_dirs({
-      "default" => { "path" => "/var/opt/gitlab/git-data" },
-      "nfs" => { "path" => "/mnt/nfs/git-data" },
-      "cephfs" => { "path" => "/mnt/cephfs/git-data" }
-    })
-    ```
+   ```ruby
+   git_data_dirs({
+     "default" => { "path" => "/var/opt/gitlab/git-data" },
+     "nfs" => { "path" => "/mnt/nfs/git-data" },
+     "cephfs" => { "path" => "/mnt/cephfs/git-data" }
+   })
+   ```
 
-    Note that Omnibus stores the repositories in a `repositories` subdirectory
-    of the `git-data` directory.
+   Note that Omnibus stores the repositories in a `repositories` subdirectory
+   of the `git-data` directory.
 
 ## Choose where new project repositories will be stored
 

doc/administration/uploads.md

@@ -23,10 +23,10 @@ _The uploads are stored by default in `/var/opt/gitlab/gitlab-rails/uploads`._
 1. To change the storage path for example to `/mnt/storage/uploads`, edit
    `/etc/gitlab/gitlab.rb` and add the following line:
 
-    ```ruby
-    gitlab_rails['uploads_storage_path'] = "/mnt/storage/"
-	gitlab_rails['uploads_base_dir'] = "uploads"
-    ```
+   ```ruby
+   gitlab_rails['uploads_storage_path'] = "/mnt/storage/"
+   gitlab_rails['uploads_base_dir'] = "uploads"
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
@@ -40,11 +40,11 @@ _The uploads are stored by default in
 1. To change the storage path for example to `/mnt/storage/uploads`, edit
    `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
 
-    ```yaml
-	uploads:
-	  storage_path: /mnt/storage
-	  base_dir: uploads
-    ```
+   ```yaml
+   uploads:
+   storage_path: /mnt/storage
+   base_dir: uploads
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 
@@ -97,27 +97,27 @@ _The uploads are stored by default in
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
    the values you want:
 
-    ```ruby
-    gitlab_rails['uploads_object_store_enabled'] = true
-    gitlab_rails['uploads_object_store_remote_directory'] = "uploads"
-    gitlab_rails['uploads_object_store_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
-      'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
-    }
-    ```
-
-	>**Note:**
-	If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
-
-    ```ruby
-    gitlab_rails['uploads_object_store_connection'] = {
-      'provider' => 'AWS',
-      'region' => 'eu-central-1',
-      'use_iam_profile' => true
-    }
-    ```
+   ```ruby
+   gitlab_rails['uploads_object_store_enabled'] = true
+   gitlab_rails['uploads_object_store_remote_directory'] = "uploads"
+   gitlab_rails['uploads_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
+     'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
+   }
+   ```
+
+   >**Note:**
+   >If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
+
+   ```ruby
+   gitlab_rails['uploads_object_store_connection'] = {
+     'provider' => 'AWS',
+     'region' => 'eu-central-1',
+     'use_iam_profile' => true
+   }
+   ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
@@ -132,17 +132,17 @@ _The uploads are stored by default in
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
 
-    ```yaml
-    uploads:
-      object_store:
-        enabled: true
-        remote_directory: "uploads" # The bucket name
-        connection:
-          provider: AWS # Only AWS supported at the moment
-          aws_access_key_id: AWS_ACESS_KEY_ID
-          aws_secret_access_key: AWS_SECRET_ACCESS_KEY
-          region: eu-central-1
-    ```
+   ```yaml
+   uploads:
+     object_store:
+       enabled: true
+       remote_directory: "uploads" # The bucket name
+       connection:
+         provider: AWS # Only AWS supported at the moment
+         aws_access_key_id: AWS_ACESS_KEY_ID
+         aws_secret_access_key: AWS_SECRET_ACCESS_KEY
+         region: eu-central-1
+   ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).

doc/api/README.md

@@ -311,9 +311,9 @@ By default, impersonation is enabled. To disable impersonation:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
-    ```ruby
-    gitlab_rails['impersonation_enabled'] = false
-    ```
+   ```ruby
+   gitlab_rails['impersonation_enabled'] = false
+   ```
 
 1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
    GitLab for the changes to take effect.
@@ -326,10 +326,10 @@ To re-enable impersonation, remove this configuration and reconfigure GitLab.
 
 1. Edit `config/gitlab.yml`:
 
-    ```yaml
-    gitlab:
-      impersonation_enabled: false
-    ```
+   ```yaml
+   gitlab:
+     impersonation_enabled: false
+   ```
 
 1. Save the file and [restart](../administration/restart_gitlab.md#installations-from-source)
    GitLab for the changes to take effect.

doc/api/lint.md

@@ -22,30 +22,30 @@ Example responses:
 
 - Valid content:
 
-    ```json
-    {
-      "status": "valid",
-      "errors": []
-    }
-    ```
+  ```json
+  {
+    "status": "valid",
+    "errors": []
+  }
+  ```
 
 - Invalid content:
 
-    ```json
-    {
-      "status": "invalid",
-      "errors": [
-        "variables config should be a hash of key value pairs"
-      ]
-    }
-    ```
+  ```json
+  {
+    "status": "invalid",
+    "errors": [
+      "variables config should be a hash of key value pairs"
+    ]
+  }
+  ```
 
 - Without the content attribute:
 
-    ```json
-    {
-      "error": "content is missing"
-    }
-    ```
+  ```json
+  {
+    "error": "content is missing"
+  }
+  ```
 
 [ce-5953]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5953

doc/api/repositories.md

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

doc/api/runners.md

@@ -20,10 +20,10 @@ Here's an example of how the two tokens are used in Runner registration:
 1. You use that authentication token and add it to the
    [Runner's configuration file](https://docs.gitlab.com/runner/commands/#configuration-file):
 
-    ```toml
-    [[runners]]
-      token = "<authentication_token>"
-    ```
+   ```toml
+   [[runners]]
+     token = "<authentication_token>"
+   ```
 
 GitLab and Runner are then connected.
 

doc/ci/git_submodules.md

@@ -79,14 +79,14 @@ correctly with your CI jobs:
 1. If you are using an older version of `gitlab-runner`, then use
    `git submodule sync/update` in `before_script`:
 
-    ```yaml
-    before_script:
-      - git submodule sync --recursive
-      - git submodule update --init --recursive
-    ```
-
-    `--recursive` should be used in either both or none (`sync/update`) depending on
-    whether you have recursive submodules.
+   ```yaml
+   before_script:
+     - git submodule sync --recursive
+     - git submodule update --init --recursive
+   ```
+
+   `--recursive` should be used in either both or none (`sync/update`) depending on
+   whether you have recursive submodules.
 
 The rationale to set the `sync` and `update` in `before_script` is because of
 the way Git submodules work. On a fresh Runner workspace, Git will set the

doc/development/architecture.md

@@ -484,9 +484,11 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
 Below we describe the different pathing that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences.
 
 ### Web Request (80/443)
+
 TODO
 
 ### SSH Request (22)
+
 TODO
 
 ## System Layout
@@ -505,7 +507,9 @@ To summarize here's the [directory structure of the `git` user home directory](.
 
 ### Processes
 
-    ps aux | grep '^git'
+```sh
+ps aux | grep '^git'
+```
 
 GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
 

doc/development/ee_features.md

@@ -182,52 +182,52 @@ There are a few gotchas with it:
   pattern](https://en.wikipedia.org/wiki/Template_method_pattern).
   For example, given this base:
 
-    ```ruby
-      class Base
-        def execute
-          return unless enabled?
+  ```ruby
+    class Base
+      def execute
+        return unless enabled?
 
-          # ...
-          # ...
-        end
+        # ...
+        # ...
       end
-    ```
+    end
+  ```
 
-    Instead of just overriding `Base#execute`, we should update it and extract
-    the behaviour into another method:
+  Instead of just overriding `Base#execute`, we should update it and extract
+  the behaviour into another method:
 
-    ```ruby
-      class Base
-        def execute
-          return unless enabled?
+  ```ruby
+    class Base
+      def execute
+        return unless enabled?
 
-          do_something
-        end
+        do_something
+      end
 
-        private
+      private
 
-        def do_something
-          # ...
-          # ...
-        end
+      def do_something
+        # ...
+        # ...
       end
-    ```
+    end
+  ```
 
-    Then we're free to override that `do_something` without worrying about the
-    guards:
+  Then we're free to override that `do_something` without worrying about the
+  guards:
 
-    ```ruby
-      module EE::Base
-        extend ::Gitlab::Utils::Override
+  ```ruby
+    module EE::Base
+      extend ::Gitlab::Utils::Override
 
-        override :do_something
-        def do_something
-          # Follow the above pattern to call super and extend it
-        end
+      override :do_something
+      def do_something
+        # Follow the above pattern to call super and extend it
       end
-    ```
+    end
+  ```
 
-    This would require updating CE first, or make sure this is back ported to CE.
+  This would require updating CE first, or make sure this is back ported to CE.
 
 When prepending, place them in the `ee/` specific sub-directory, and
 wrap class or module in `module EE` to avoid naming conflicts.
@@ -1038,8 +1038,8 @@ to avoid conflicts during CE to EE merge.
 Until the work completed to merge the ce and ee codebases, which is tracked on [epic &802](https://gitlab.com/groups/gitlab-org/-/epics/802), there exists times in which some changes for EE require specific changes to the CE
 code base.  Examples of backports include the following:
 
-* Features intended or originally built for EE that are later decided to move to CE
-* Sometimes some code in CE may impact the EE feature
+- Features intended or originally built for EE that are later decided to move to CE
+- Sometimes some code in CE may impact the EE feature
 
 Here is a workflow to make sure those changes end up backported safely into CE too.
 

doc/development/emails.md

@@ -26,51 +26,51 @@ See the [Rails guides] for more info.
    feature and fill in the details for your specific IMAP server and email
    account:
 
-    Configuration for Gmail / Google Apps, assumes mailbox gitlab-incoming@gmail.com
-
-    ```yaml
-    incoming_email:
-      enabled: true
-
-      # The email address including the `%{key}` placeholder that will be replaced to reference the item being replied to.
-      # The placeholder can be omitted but if present, it must appear in the "user" part of the address (before the `@`).
-      address: "gitlab-incoming+%{key}@gmail.com"
-
-      # Email account username
-      # With third party providers, this is usually the full email address.
-      # With self-hosted email servers, this is usually the user part of the email address.
-      user: "gitlab-incoming@gmail.com"
-      # Email account password
-      password: "[REDACTED]"
-
-      # IMAP server host
-      host: "imap.gmail.com"
-      # IMAP server port
-      port: 993
-      # Whether the IMAP server uses SSL
-      ssl: true
-      # Whether the IMAP server uses StartTLS
-      start_tls: false
-
-      # The mailbox where incoming mail will end up. Usually "inbox".
-      mailbox: "inbox"
-      # The IDLE command timeout.
-      idle_timeout: 60
-    ```
-
-    As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`.
+   Configuration for Gmail / Google Apps, assumes mailbox `gitlab-incoming@gmail.com`:
+
+   ```yaml
+   incoming_email:
+     enabled: true
+
+     # The email address including the `%{key}` placeholder that will be replaced to reference the item being replied to.
+     # The placeholder can be omitted but if present, it must appear in the "user" part of the address (before the `@`).
+     address: "gitlab-incoming+%{key}@gmail.com"
+
+     # Email account username
+     # With third party providers, this is usually the full email address.
+     # With self-hosted email servers, this is usually the user part of the email address.
+     user: "gitlab-incoming@gmail.com"
+     # Email account password
+     password: "[REDACTED]"
+
+     # IMAP server host
+     host: "imap.gmail.com"
+     # IMAP server port
+     port: 993
+     # Whether the IMAP server uses SSL
+     ssl: true
+     # Whether the IMAP server uses StartTLS
+     start_tls: false
+
+     # The mailbox where incoming mail will end up. Usually "inbox".
+     mailbox: "inbox"
+     # The IDLE command timeout.
+     idle_timeout: 60
+   ```
+
+   As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`.
 
 1. Run this command in the GitLab root directory to launch `mail_room`:
 
-    ```sh
-    bundle exec mail_room -q -c config/mail_room.yml
-    ```
+   ```sh
+   bundle exec mail_room -q -c config/mail_room.yml
+   ```
 
 1. Verify that everything is configured correctly:
 
-    ```sh
-    bundle exec rake gitlab:incoming_email:check RAILS_ENV=development
-    ```
+   ```sh
+   bundle exec rake gitlab:incoming_email:check RAILS_ENV=development
+   ```
 
 1. Reply by email should now be working.
 
@@ -91,10 +91,10 @@ for the format of the email key:
 
 Examples of valid email keys:
 
- - `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue)
- - `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request)
- - `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation)
- - `1234567890abcdef1234567890abcdef` (reply to a conversation)
+- `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue)
+- `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request)
+- `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation)
+- `1234567890abcdef1234567890abcdef` (reply to a conversation)
 
 Please note that the action `-issue-` is used in GitLab Premium as the handler for the Service Desk feature.
 
@@ -103,10 +103,10 @@ Please note that the action `-issue-` is used in GitLab Premium as the handler f
 Although we continue to support the older legacy format, no new features should use a legacy format.
 These are the only valid legacy formats for an email handler:
 
- - `path/to/project+namespace`
- - `path/to/project+namespace+action`
- - `namespace`
- - `namespace+action`
+- `path/to/project+namespace`
+- `path/to/project+namespace+action`
+- `namespace`
+- `namespace+action`
 
 Please note that `path/to/project` is used in GitLab Premium as handler for the Service Desk feature.
 

doc/development/gotchas.md

@@ -101,10 +101,10 @@ end
   in a prepended module, which is very likely the case in EE. We could see
   error like this:
 
-    ```
-    1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages)
-         Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
-    ```
+  ```
+  1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages)
+       Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
+  ```
 
 ### Alternative: `expect_next_instance_of`
 

doc/development/logging.md

@@ -30,8 +30,8 @@ Completed 200 OK in 166ms (Views: 117.4ms | ActiveRecord: 27.2ms)
 These logs suffer from a number of problems:
 
 1. They often lack timestamps or other contextual information (e.g. project ID, user)
-2. They may span multiple lines, which make them hard to find via Elasticsearch.
-3. They lack a common structure, which make them hard to parse by log
+1. They may span multiple lines, which make them hard to find via Elasticsearch.
+1. They lack a common structure, which make them hard to parse by log
    forwarders, such as Logstash or Fluentd. This also makes them hard to
    search.
 
@@ -67,46 +67,46 @@ importer progresses. Here's what to do:
    make it easy for people to search pertinent logs in one place. For
    example, `geo.log` contains all logs pertaining to GitLab Geo.
    To create a new file:
-    1. Choose a filename (e.g. `importer_json.log`).
-    1. Create a new subclass of `Gitlab::JsonLogger`:
-
-        ```ruby
-        module Gitlab
-          module Import
-            class Logger < ::Gitlab::JsonLogger
-              def self.file_name_noext
-                'importer'
-              end
+   1. Choose a filename (e.g. `importer_json.log`).
+   1. Create a new subclass of `Gitlab::JsonLogger`:
+
+      ```ruby
+      module Gitlab
+        module Import
+          class Logger < ::Gitlab::JsonLogger
+            def self.file_name_noext
+              'importer'
             end
-           end
-        end
-        ```
+          end
+         end
+      end
+      ```
 
-    1. In your class where you want to log, you might initialize the logger as an instance variable:
+   1. In your class where you want to log, you might initialize the logger as an instance variable:
 
-        ```ruby
-        attr_accessor :logger
+      ```ruby
+      attr_accessor :logger
 
-        def initialize
-          @logger = Gitlab::Import::Logger.build
-        end
-        ```
+      def initialize
+        @logger = Gitlab::Import::Logger.build
+      end
+      ```
 
-        Note that it's useful to memoize this because creating a new logger
-        each time you log will open a file, adding unnecessary overhead.
+      Note that it's useful to memoize this because creating a new logger
+      each time you log will open a file, adding unnecessary overhead.
 
 1. Now insert log messages into your code. When adding logs,
    make sure to include all the context as key-value pairs:
 
-    ```ruby
-    # BAD
-    logger.info("Unable to create project #{project.id}")
-    ```
+   ```ruby
+   # BAD
+   logger.info("Unable to create project #{project.id}")
+   ```
 
-    ```ruby
-    # GOOD
-    logger.info(message: "Unable to create project", project_id: project.id)
-    ```
+   ```ruby
+   # GOOD
+   logger.info(message: "Unable to create project", project_id: project.id)
+   ```
 
 1. Be sure to create a common base structure of your log messages. For example,
    all messages might have `current_user_id` and `project_id` to make it easier
@@ -116,16 +116,16 @@ importer progresses. Here's what to do:
    logs properly if you [mix integer and string
    types](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_avoiding_type_gotchas):
 
-    ```ruby
-    # BAD
-    logger.info(message: "Import error", error: 1)
-    logger.info(message: "Import error", error: "I/O failure")
-    ```
+   ```ruby
+   # BAD
+   logger.info(message: "Import error", error: 1)
+   logger.info(message: "Import error", error: "I/O failure")
+   ```
 
-    ```ruby
-    # GOOD
-    logger.info(message: "Import error", error_code: 1, error: "I/O failure")
-    ```
+   ```ruby
+   # GOOD
+   logger.info(message: "Import error", error_code: 1, error: "I/O failure")
+   ```
 
 ## Additional steps with new log files
 

doc/development/profiling.md

@@ -95,7 +95,9 @@ Sherlock is a custom profiling tool built into GitLab. Sherlock is _only_
 available when running GitLab in development mode _and_ when setting the
 environment variable `ENABLE_SHERLOCK` to a non empty value. For example:
 
-    ENABLE_SHERLOCK=1 bundle exec rails s
+```sh
+ENABLE_SHERLOCK=1 bundle exec rails s
+```
 
 Recorded transactions can be found by navigating to `/sherlock/transactions`.
 
@@ -106,7 +108,9 @@ Bullet adds quite a bit of logging noise it's disabled by default. To enable
 Bullet, set the environment variable `ENABLE_BULLET` to a non-empty value before
 starting GitLab. For example:
 
-    ENABLE_BULLET=true bundle exec rails s
+```sh
+ENABLE_BULLET=true bundle exec rails s
+```
 
 Bullet will log query problems to both the Rails log as well as the Chrome
 console.

doc/development/routing.md

@@ -7,11 +7,15 @@ support subgroups, GitLab project and group routes use the wildcard
 character to match project and group routes. For example, we might have
 a path such as:
 
-    /gitlab-com/customer-success/north-america/west/customerA
+```
+/gitlab-com/customer-success/north-america/west/customerA
+```
 
 However, paths can be ambiguous. Consider the following example:
 
-    /gitlab-com/edit
+```
+/gitlab-com/edit
+```
 
 It's ambiguous whether there is a subgroup named `edit` or whether
 this is a special endpoint to edit the `gitlab-com` group.
@@ -25,8 +29,10 @@ number of [reserved names](../user/reserved_names.md).
 
 We have a number of global routes. For example:
 
-    /-/health
-    /-/metrics
+```
+/-/health
+/-/metrics
+```
 
 ## Group routes
 
@@ -34,10 +40,12 @@ Every group route must be under the `/-/` scope.
 
 Examples:
 
-    gitlab-org/-/edit
-    gitlab-org/-/activity
-    gitlab-org/-/security/dashboard
-    gitlab-org/serverless/-/activity
+```
+gitlab-org/-/edit
+gitlab-org/-/activity
+gitlab-org/-/security/dashboard
+gitlab-org/serverless/-/activity
+```
 
 To achieve that, use the `scope '-'` method.
 
@@ -48,10 +56,12 @@ client or other software requires something different.
 
 Examples:
 
-    gitlab-org/gitlab-ce/-/activity
-    gitlab-org/gitlab-ce/-/jobs/123
-    gitlab-org/gitlab-ce/-/settings/repository
-    gitlab-org/serverless/runtimes/-/settings/repository
+```
+gitlab-org/gitlab-ce/-/activity
+gitlab-org/gitlab-ce/-/jobs/123
+gitlab-org/gitlab-ce/-/settings/repository
+gitlab-org/serverless/runtimes/-/settings/repository
+```
 
 Currently, only some project routes are placed under the `/-/` scope. However,
 you can help us migrate more of them! To migrate project routes:

doc/development/sql.md

@@ -94,7 +94,9 @@ on the amount of data indexed).
 To keep naming of these indexes consistent please use the following naming
 pattern:
 
-    index_TABLE_on_COLUMN_trigram
+```
+index_TABLE_on_COLUMN_trigram
+```
 
 For example, a GIN/trigram index for `issues.title` would be called
 `index_issues_on_title_trigram`.