Add more rules to markdown lint check

Adds MD010 (Hard tabs), MD012 (blank lines), MD029 (ordered
list prefix), MD030 (spaces after list markers), and fixes
remaining docs that were failing these tests

6 files changed, 122 insertions, 172 deletions

diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 78d040cda99..3445f916ef4 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -74,43 +74,38 @@ The OpenID Connect will provide you with a client details and secret for you to
        }
    ```
 
-   > **Note:**
-   >
-   > - For more information on each configuration option refer to
-       the [OmniAuth OpenID Connect usage documentation](https://github.com/m0n9oose/omniauth_openid_connect#usage) and
-       the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).
+   NOTE: **Note:**
+   For more information on each configuration option refer to the [OmniAuth OpenID Connect usage documentation](https://github.com/m0n9oose/omniauth_openid_connect#usage)
+   and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).
 
 1. For the configuration above, change the values for the provider to match your OpenID Connect client setup. Use the following as a guide:
-    - `<your_oidc_label>` is the label that will be displayed on the login page.
-    - `<your_oidc_url>` (optional) is the URL that points to the OpenID Connect provider. For example, `https://example.com/auth/realms/your-realm`.
-      If this value is not provided, the URL is constructed from the `client_options` in the following format: `<client_options.scheme>://<client_options.host>:<client_options.port>`.
-    - If `discovery` is set to `true`, the OpenID Connect provider will try to auto discover the client options using `<your_oidc_url>/.well-known/openid-configuration`. Defaults to `false`.
-    - `client_auth_method` (optional) specifies the method used for authenticating the client with the OpenID Connect provider.
-      - Supported values are:
-        - `basic` - HTTP Basic Authentication
-        - `jwt_bearer` - JWT based authentication (private key and client secret signing)
-        - `mtls` - Mutual TLS or X.509 certificate validation
-        - Any other value will POST the client id and secret in the request body
-      - If not specified, defaults to `basic`.
-    - `<uid_field>` (optional) is the field name from the `user_info` details that will be used as `uid` value. For example, `preferred_username`.
-      If this value is not provided or the field with the configured value is missing from the `user_info` details, the `uid` will use the `sub` field.
-    - `client_options` are the OpenID Connect client-specific options. Specifically:
-
-      - `identifier` is the client identifier as configured in the OpenID Connect service provider.
-      - `secret` is the client secret as configured in the OpenID Connect service provider.
-      - `redirect_uri` is the GitLab URL to redirect the user to after successful login. For example, `http://example.com/users/auth/openid_connect/callback`.
-      - `end_session_endpoint` (optional) is the URL to the endpoint that end the session (logout). Can be provided if auto-discovery disabled or unsuccessful.
-
-      The following `client_options` are optional unless auto-discovery is disabled or unsuccessful:
-
-        - `authorization_endpoint` is the URL to the endpoint that authorizes the end user.
-        - `token_endpoint` is the URL to the endpoint that provides Access Token.
-        - `userinfo_endpoint` is the URL to the endpoint that provides the user information.
-        - `jwks_uri` is the URL to the endpoint where the Token signer publishes its keys.
-
-1.  Save the configuration file.
-1.  [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source)
-    for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
+   - `<your_oidc_label>` is the label that will be displayed on the login page.
+   - `<your_oidc_url>` (optional) is the URL that points to the OpenID Connect provider. For example, `https://example.com/auth/realms/your-realm`.
+     If this value is not provided, the URL is constructed from the `client_options` in the following format: `<client_options.scheme>://<client_options.host>:<client_options.port>`.
+   - If `discovery` is set to `true`, the OpenID Connect provider will try to auto discover the client options using `<your_oidc_url>/.well-known/openid-configuration`. Defaults to `false`.
+   - `client_auth_method` (optional) specifies the method used for authenticating the client with the OpenID Connect provider.
+     - Supported values are:
+       - `basic` - HTTP Basic Authentication
+       - `jwt_bearer` - JWT based authentication (private key and client secret signing)
+       - `mtls` - Mutual TLS or X.509 certificate validation
+       - Any other value will POST the client id and secret in the request body
+     - If not specified, defaults to `basic`.
+   - `<uid_field>` (optional) is the field name from the `user_info` details that will be used as `uid` value. For example, `preferred_username`.
+     If this value is not provided or the field with the configured value is missing from the `user_info` details, the `uid` will use the `sub` field.
+   - `client_options` are the OpenID Connect client-specific options. Specifically:
+     - `identifier` is the client identifier as configured in the OpenID Connect service provider.
+     - `secret` is the client secret as configured in the OpenID Connect service provider.
+     - `redirect_uri` is the GitLab URL to redirect the user to after successful login. For example, `http://example.com/users/auth/openid_connect/callback`.
+     - `end_session_endpoint` (optional) is the URL to the endpoint that end the session (logout). Can be provided if auto-discovery disabled or unsuccessful.
+     - The following `client_options` are optional unless auto-discovery is disabled or unsuccessful:
+       - `authorization_endpoint` is the URL to the endpoint that authorizes the end user.
+       - `token_endpoint` is the URL to the endpoint that provides Access Token.
+       - `userinfo_endpoint` is the URL to the endpoint that provides the user information.
+       - `jwks_uri` is the URL to the endpoint where the Token signer publishes its keys.
+
+1. Save the configuration file.
+1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source)
+   for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
 On the sign in page, there should now be an OpenID Connect icon below the regular sign in form.
 Click the icon to begin the authentication process. The OpenID Connect provider will ask the user to
diff --git a/doc/administration/container_registry.md b/doc/administration/container_registry.md
index 3e3054af509..e418938451a 100644
--- a/doc/administration/container_registry.md
+++ b/doc/administration/container_registry.md
@@ -27,8 +27,6 @@ but not recommended and out of the scope of this document.
 Read the [insecure Registry documentation][docker-insecure] if you want to
 implement this.
 
----
-
 **Installations from source**
 
 If you have installed GitLab from source:
@@ -116,8 +114,6 @@ GitLab from source respectively.
 Be careful to choose a port different than the one that Registry listens to (`5000` by default),
 otherwise you will run into conflicts.
 
----
-
 **Omnibus GitLab installations**
 
 1. Your `/etc/gitlab/gitlab.rb` should contain the Registry URL as well as the
@@ -141,8 +137,6 @@ otherwise you will run into conflicts.
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **Installations from source**
 
 1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
@@ -158,8 +152,6 @@ otherwise you will run into conflicts.
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
 
----
-
 Users should now be able to login to the Container Registry with their GitLab
 credentials using:
 
@@ -177,8 +169,6 @@ domain (e.g., `registry.gitlab.example.com`).
 Let's assume that you want the container Registry to be accessible at
 `https://registry.gitlab.example.com`.
 
----
-
 **Omnibus GitLab installations**
 
 1. Place your TLS certificate and key in
@@ -210,8 +200,6 @@ look like:
 > registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
 > ```
 
----
-
 **Installations from source**
 
 1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
@@ -226,8 +214,6 @@ look like:
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
 
----
-
 Users should now be able to login to the Container Registry using their GitLab
 credentials:
 
@@ -252,8 +238,6 @@ Registry application itself.
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **Installations from source**
 
 1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
@@ -272,8 +256,6 @@ If the Container Registry is enabled, then it will be available on all new
 projects. To disable this function and let the owners of a project to enable
 the Container Registry by themselves, follow the steps below.
 
----
-
 **Omnibus GitLab installations**
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
@@ -284,8 +266,6 @@ the Container Registry by themselves, follow the steps below.
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **Installations from source**
 
 1. Open `/home/git/gitlab/config/gitlab.yml`, find the `default_projects_features`
@@ -321,8 +301,6 @@ This path is accessible to:
 > **Warning** You should confirm that all GitLab, Registry and web server users
 have access to this directory.
 
----
-
 **Omnibus GitLab installations**
 
 The default location where images are stored in Omnibus, is
@@ -336,8 +314,6 @@ The default location where images are stored in Omnibus, is
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **Installations from source**
 
 The default location where images are stored in source installations, is
@@ -446,8 +422,6 @@ In the examples below we set the Registry's port to `5001`.
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **Installations from source**
 
 1. Open the configuration file of your Registry server and edit the
@@ -565,8 +539,6 @@ To configure a notification endpoint in Omnibus:
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **Installations from source**
 
 Configuring the notification endpoint is done in your registry config YML file created
@@ -640,8 +612,6 @@ Start with a value between `25000000` (25MB) and `50000000` (50MB).
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **For installations from source**
 
 1. Edit `config/gitlab.yml`:
@@ -673,8 +643,6 @@ You can add a configuration option for backwards compatibility.
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 
----
-
 **For installations from source**
 
 1. Edit the YML configuration file you created when you [deployed the registry][registry-deploy]. Add the following snippet:
diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md
index dc49a95e008..5aedb665935 100644
--- a/doc/administration/geo/replication/index.md
+++ b/doc/administration/geo/replication/index.md
@@ -14,14 +14,8 @@ Fetching large repositories can take a long time for teams located far from a si
 
 Geo provides local, read-only instances of your GitLab instances, reducing the time it takes to clone and fetch large repositories and speeding up development.
 
-> **Notes:**
->
-> - Geo is part of [GitLab Premium](https://about.gitlab.com/pricing/#self-managed).
-> - We recommend you use:
->   - At least GitLab Enterprise Edition 10.0 for basic Geo features.
->   - The latest version for a better experience.
-> - Make sure that all nodes run the same GitLab version.
-> - Geo requires PostgreSQL 9.6 and Git 2.9, in addition to GitLab's usual [minimum requirements](../../../install/requirements.md).
+NOTE: **Note:**
+Check the [requirements](#requirements-for-running-geo) carefully before setting up Geo.
 
 For a video introduction to Geo, see [Introduction to GitLab Geo - GitLab Features](https://www.youtube.com/watch?v=-HDLxSjEh6w).
 
@@ -117,6 +111,13 @@ The following are required to run Geo:
   - [Ubuntu](https://www.ubuntu.com) 16.04+
 - PostgreSQL 9.6+ with [FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support and [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication)
 - Git 2.9+
+- All nodes must run the same GitLab version.
+
+Additionally, check GitLab's [minimum requirements](../../../install/requirements.md),
+and we recommend you use:
+
+- At least GitLab Enterprise Edition 10.0 for basic Geo features.
+- The latest version for a better experience.
 
 ### Firewall rules
 
diff --git a/doc/administration/high_availability/pgbouncer.md b/doc/administration/high_availability/pgbouncer.md
index 0b945bc6244..b99724d12a2 100644
--- a/doc/administration/high_availability/pgbouncer.md
+++ b/doc/administration/high_availability/pgbouncer.md
@@ -20,84 +20,85 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
 1. Edit `/etc/gitlab/gitlab.rb` replacing values noted in the `# START user configuration` section:
 
-    ```ruby
-    # Disable all components except Pgbouncer and Consul agent
-    roles ['pgbouncer_role']
-
-    # Configure Pgbouncer
-    pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
-
-    # Configure Consul agent
-    consul['watchers'] = %w(postgresql)
-
-    # START user configuration
-    # Please set the real values as explained in Required Information section
-    # Replace CONSUL_PASSWORD_HASH with with a generated md5 value
-    # Replace PGBOUNCER_PASSWORD_HASH with with a generated md5 value
-    pgbouncer['users'] = {
-      'gitlab-consul': {
-        password: 'CONSUL_PASSWORD_HASH'
-      },
-      'pgbouncer': {
-        password: 'PGBOUNCER_PASSWORD_HASH'
-      }
-    }
-    # Replace placeholders:
-    #
-    # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
-    # with the addresses gathered for CONSUL_SERVER_NODES
-    consul['configuration'] = {
-      retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z)
-    }
-    #
-    # END user configuration
-    ```
-
-    > `pgbouncer_role` was introduced with GitLab 10.3
-
-1.  Run `gitlab-ctl reconfigure`
+   ```ruby
+   # Disable all components except Pgbouncer and Consul agent
+   roles ['pgbouncer_role']
+
+   # Configure Pgbouncer
+   pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
+
+   # Configure Consul agent
+   consul['watchers'] = %w(postgresql)
+
+   # START user configuration
+   # Please set the real values as explained in Required Information section
+   # Replace CONSUL_PASSWORD_HASH with with a generated md5 value
+   # Replace PGBOUNCER_PASSWORD_HASH with with a generated md5 value
+   pgbouncer['users'] = {
+     'gitlab-consul': {
+       password: 'CONSUL_PASSWORD_HASH'
+     },
+     'pgbouncer': {
+       password: 'PGBOUNCER_PASSWORD_HASH'
+     }
+   }
+   # Replace placeholders:
+   #
+   # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
+   # with the addresses gathered for CONSUL_SERVER_NODES
+   consul['configuration'] = {
+     retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z)
+   }
+   #
+   # END user configuration
+   ```
+
+   NOTE: **Note:**
+   `pgbouncer_role` was introduced with GitLab 10.3.
+
+1. Run `gitlab-ctl reconfigure`
 
 1. Create a `.pgpass` file so Consul is able to
    reload pgbouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
 
-    ```sh
-    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
-    ```
+   ```sh
+   gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
+   ```
 
 #### PGBouncer Checkpoint
 
 1. Ensure the node is talking to the current master:
 
-    ```sh
-    gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
-    ```
+   ```sh
+   gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
+   ```
 
-    If there is an error `psql: ERROR:  Auth failed` after typing in the
-    password, ensure you previously generated the MD5 password hashes with the correct
-    format. The correct format is to concatenate the password and the username:
-    `PASSWORDUSERNAME`. For example, `Sup3rS3cr3tpgbouncer` would be the text
-    needed to generate an MD5 password hash for the `pgbouncer` user.
+   If there is an error `psql: ERROR:  Auth failed` after typing in the
+   password, ensure you previously generated the MD5 password hashes with the correct
+   format. The correct format is to concatenate the password and the username:
+   `PASSWORDUSERNAME`. For example, `Sup3rS3cr3tpgbouncer` would be the text
+   needed to generate an MD5 password hash for the `pgbouncer` user.
 
 1. Once the console prompt is available, run the following queries:
 
-    ```sh
-    show databases ; show clients ;
-    ```
-
-    The output should be similar to the following:
+   ```sh
+   show databases ; show clients ;
+   ```
 
-    ```
-            name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
-    ---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
-     gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
-     pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
-    (2 rows)
+   The output should be similar to the following:
 
-     type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
-    ------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
-     C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
-    (2 rows)
-    ```
+   ```
+           name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
+   ---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
+    gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
+    pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
+   (2 rows)
+
+    type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
+   ------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
+    C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
+   (2 rows)
+   ```
 
 ### Running Pgbouncer as part of a non-HA GitLab installation
 
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index b2cad6cf926..c77a1a9638f 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -24,8 +24,6 @@ SNI and exposes pages using HTTP2 by default.
 You are encouraged to read its [README][pages-readme] to fully understand how
 it works.
 
----
-
 In the case of [custom domains](#custom-domains) (but not
 [wildcard domains](#wildcard-domains)), the Pages daemon needs to listen on
 ports `80` and/or `443`. For that reason, there is some flexibility in the way
@@ -92,8 +90,6 @@ since that is needed in all configurations.
 
 - [Wildcard DNS setup](#dns-configuration)
 
----
-
 URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
@@ -152,13 +148,12 @@ The Pages daemon doesn't listen to the outside world.
 
 ### Wildcard domains with TLS support
 
-> **Requirements:**
-> - [Wildcard DNS setup](#dns-configuration)
-> - Wildcard TLS certificate
->
-> ---
->
-> URL scheme: `https://page.example.io`
+**Requirements:**
+
+- [Wildcard DNS setup](#dns-configuration)
+- Wildcard TLS certificate
+
+URL scheme: `https://page.example.io`
 
 Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
@@ -217,13 +212,12 @@ that without TLS certificates.
 
 ### Custom domains
 
-> **Requirements:**
-> - [Wildcard DNS setup](#dns-configuration)
-> - Secondary IP
->
-> ---
->
-> URL scheme: `http://page.example.io` and `http://domain.com`
+**Requirements:**
+
+- [Wildcard DNS setup](#dns-configuration)
+- Secondary IP
+
+URL scheme: `http://page.example.io` and `http://domain.com`
 
 In that case, the pages daemon is running, Nginx still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
@@ -282,14 +276,13 @@ world. Custom domains are supported, but no TLS.
 
 ### Custom domains with TLS support
 
-> **Requirements:**
-> - [Wildcard DNS setup](#dns-configuration)
-> - Wildcard TLS certificate
-> - Secondary IP
->
-> ---
->
-> URL scheme: `https://page.example.io` and `https://domain.com`
+**Requirements:**
+
+- [Wildcard DNS setup](#dns-configuration)
+- Wildcard TLS certificate
+- Secondary IP
+
+URL scheme: `https://page.example.io` and `https://domain.com`
 
 In that case, the pages daemon is running, Nginx still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md
index 2f83dd17d9f..1198f3414c5 100644
--- a/doc/administration/raketasks/storage.md
+++ b/doc/administration/raketasks/storage.md
@@ -105,8 +105,6 @@ sudo gitlab-rake gitlab:storage:legacy_projects
 sudo -u git -H bundle exec rake gitlab:storage:legacy_projects RAILS_ENV=production
 ```
 
----
-
 To list projects using **Legacy** storage:
 
 **Omnibus Installation**
@@ -138,8 +136,6 @@ sudo gitlab-rake gitlab:storage:hashed_projects
 sudo -u git -H bundle exec rake gitlab:storage:hashed_projects RAILS_ENV=production
 ```
 
----
-
 To list projects using **Hashed** storage:
 
 **Omnibus Installation**
@@ -170,8 +166,6 @@ sudo gitlab-rake gitlab:storage:legacy_attachments
 sudo -u git -H bundle exec rake gitlab:storage:legacy_attachments RAILS_ENV=production
 ```
 
----
-
 To list project attachments using **Legacy** storage:
 
 **Omnibus Installation**
@@ -202,8 +196,6 @@ sudo gitlab-rake gitlab:storage:hashed_attachments
 sudo -u git -H bundle exec rake gitlab:storage:hashed_attachments RAILS_ENV=production
 ```
 
----
-
 To list project attachments using **Hashed** storage:
 
 **Omnibus Installation**