Fix markdown in various docs

Clean up issues that may cause the docs-lint
test to fail, such as trailing whitespace, no
EOF newline, blockquotes, etc

13 files changed, 51 insertions, 68 deletions

diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
index 86dd398343b..7c14d4004db 100644
--- a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
+++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
@@ -32,7 +32,7 @@ For example, [Active Directory](https://technet.microsoft.com/en-us/library/hh83
 
 We won't cover the installation and configuration of Windows Server or Active Directory Domain Services in this tutorial. There are a number of resources online to guide you through this process:
 
-- Install Windows Server 2012  - (_technet.microsoft.com_) - [Installing Windows Server 2012 ](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
+- Install Windows Server 2012  - (_technet.microsoft.com_) - [Installing Windows Server 2012](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
 
 - Install Active Directory Domain Services (AD DS) (_technet.microsoft.com_)- [Install Active Directory Domain Services](https://technet.microsoft.com/windows-server-docs/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-#BKMK_PS)
 
@@ -249,7 +249,7 @@ After configuring LDAP, basic authentication will be available. Users can then l
 
 Users that are removed from the LDAP base group (e.g `OU=GitLab INT,DC=GitLab,DC=org`) will be **blocked** in GitLab. [More information](../ldap.md#security) on LDAP security.
 
-If `allow_username_or_email_login` is enabled in the LDAP configuration, GitLab will ignore everything after the first '@' in the LDAP username used on login. Example: The username `` jon.doe@example.com `` is converted to `jon.doe` when authenticating with the LDAP server. Disable this setting if you use `userPrincipalName` as the `uid`.
+If `allow_username_or_email_login` is enabled in the LDAP configuration, GitLab will ignore everything after the first '@' in the LDAP username used on login. Example: The username `jon.doe@example.com` is converted to `jon.doe` when authenticating with the LDAP server. Disable this setting if you use `userPrincipalName` as the `uid`.
 
 ## LDAP extended features on GitLab EE
 
diff --git a/doc/administration/auth/okta.md b/doc/administration/auth/okta.md
index 5524c3ba092..41745e8caae 100644
--- a/doc/administration/auth/okta.md
+++ b/doc/administration/auth/okta.md
@@ -98,20 +98,20 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
    >**Notes:**
    >
    >- Change the value for `assertion_consumer_service_url` to match the HTTPS endpoint
-      of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
-      installation to generate the correct value).
+   >  of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
+   >  installation to generate the correct value).
    >
    >- To get the `idp_cert_fingerprint` fingerprint, first download the
-      certificate from the Okta app you registered and then run:
-      `openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
-      with the location of your certificate.
+   >  certificate from the Okta app you registered and then run:
+   >  `openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
+   >  with the location of your certificate.
    >
    >- Change the value of `idp_sso_target_url`, with the value of the
-      **Identity Provider Single Sign-On URL** from the step when you
-      configured the Okta app.
+   >  **Identity Provider Single Sign-On URL** from the step when you
+   >  configured the Okta app.
    >
    >- Change the value of `issuer` to the value of the **Audience Restriction** from your Okta app configuration. This will identify GitLab
-      to the IdP.
+   >  to the IdP.
    >
    >- Leave `name_identifier_format` as-is.
 
diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index ba95843b0b0..407539885a6 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -297,7 +297,7 @@ for another **primary** node. All the old replication settings will be overwritt
 
 ## Troubleshooting
 
-### I followed the disaster recovery instructions and now two-factor auth is broken!
+### I followed the disaster recovery instructions and now two-factor auth is broken
 
 The setup instructions for Geo prior to 10.5 failed to replicate the
 `otp_key_base` secret, which is used to encrypt the two-factor authentication
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index fe1557fd8b5..3ae92b07736 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -538,7 +538,7 @@ can simply reset the existing tracking database with:
 sudo gitlab-rake geo:db:reset
 ```
 
-### Geo node has a database that is writable which is an indication it is not configured for replication with the primary node.
+### Geo node has a database that is writable which is an indication it is not configured for replication with the primary node
 
 This error refers to a problem with the database replica on a **secondary** node,
 which Geo expects to have access to. It usually means, either:
@@ -552,7 +552,7 @@ PostgreSQL instances:
 - A read-only replica of the **primary** node.
 - A regular, writable instance that holds replication metadata. That is, the Geo tracking database.
 
-### Geo node does not appear to be replicating the database from the primary node.
+### Geo node does not appear to be replicating the database from the primary node
 
 The most common problems that prevent the database from replicating correctly are:
 
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index daec5f14e36..eab4b2c6eea 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -185,7 +185,7 @@ Check the directory layout on your Gitaly server to be sure.
    ```
 
 1. Append the following to `/etc/gitlab/gitlab.rb` for each respective server:
-   
+
    For `gitaly1.internal`:
 
    ```
@@ -194,7 +194,7 @@ Check the directory layout on your Gitaly server to be sure.
      { 'name' => 'storage1' },
    ]
    ```
-   
+
    For `gitaly2.internal`:
 
    ```
@@ -226,7 +226,7 @@ Check the directory layout on your Gitaly server to be sure.
    ```
 
 1. Append the following to `/home/git/gitaly/config.toml` for each respective server:
-   
+
    For `gitaly1.internal`:
 
    ```toml
@@ -236,7 +236,7 @@ Check the directory layout on your Gitaly server to be sure.
    [[storage]]
    name = 'storage1'
    ```
-   
+
    For `gitaly2.internal`:
 
    ```toml
@@ -262,12 +262,12 @@ Additionally, you need to
 [disable Rugged if previously manually enabled](../high_availability/nfs.md#improving-nfs-performance-with-gitlab).
 
 We assume that your `gitaly1.internal` Gitaly server can be reached at
-`gitaly1.internal:8075` from your GitLab server, and that Gitaly server 
+`gitaly1.internal:8075` from your GitLab server, and that Gitaly server
 can read and write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1`.
 
 We assume also that your `gitaly2.internal` Gitaly server can be reached at
-`gitaly2.internal:8075` from your GitLab server, and that Gitaly server 
-can read and write to `/mnt/gitlab/storage2`. 
+`gitaly2.internal:8075` from your GitLab server, and that Gitaly server
+can read and write to `/mnt/gitlab/storage2`.
 
 **For Omnibus GitLab**
 
@@ -540,6 +540,7 @@ gitaly['concurrency'] = [
   }
 ]
 ```
+
 This will limit the number of in-flight RPC calls for the given RPC's.
 The limit is applied per repository. In the example above, each on the
 Gitaly server can have at most 20 simultaneous PostUploadPack calls in
@@ -729,4 +730,4 @@ To remove the proxy setting, run the following commands (depending on which vari
 ```bash
 unset http_proxy
 unset https_proxy
-```
\ No newline at end of file
+```
diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md
index 8818a9606de..0d1dd06871a 100644
--- a/doc/administration/high_availability/gitlab.md
+++ b/doc/administration/high_availability/gitlab.md
@@ -4,9 +4,9 @@ type: reference
 
 # Configuring GitLab for Scaling and High Availability
 
-> **Note:** There is some additional configuration near the bottom for
-  additional GitLab application servers. It's important to read and understand
-  these additional steps before proceeding with GitLab installation.
+NOTE: **Note:** There is some additional configuration near the bottom for
+additional GitLab application servers. It's important to read and understand
+these additional steps before proceeding with GitLab installation.
 
 1. If necessary, install the NFS client utility packages using the following
    commands:
@@ -82,19 +82,19 @@ type: reference
 
 1. [Enable monitoring](#enable-monitoring)
 
-   > **Note:** To maintain uniformity of links across HA clusters, the `external_url`
+   NOTE: **Note:** To maintain uniformity of links across HA clusters, the `external_url`
    on the first application server as well as the additional application
    servers should point to the external url that users will use to access GitLab.
    In a typical HA setup, this will be the url of the load balancer which will
    route traffic to all GitLab application servers in the HA cluster.
-   >
-   > **Note:** When you specify `https` in the `external_url`, as in the example
+
+   NOTE: **Note:** When you specify `https` in the `external_url`, as in the example
    above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
    certificates are not present, Nginx will fail to start. See
    [Nginx documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
    for more information.
-   >
-   > **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
+
+   NOTE: **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
    of GitLab. Omnibus will not recursively `chown` directories if set after the initial reconfigure.
 
 ## First GitLab application server
@@ -105,8 +105,8 @@ Do not run this on additional application servers.
 1. Initialize the database by running `sudo gitlab-rake gitlab:setup`.
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
-> **WARNING:** Only run this setup task on **NEW** GitLab instances because it
-  will wipe any existing data.
+   CAUTION: **WARNING:** Only run this setup task on **NEW** GitLab instances because it
+   will wipe any existing data.
 
 ## Extra configuration for additional GitLab application servers
 
@@ -173,9 +173,10 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
 
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
-> **Warning:** After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
-  it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
-  For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
+   CAUTION: **Warning:**
+   After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
+   it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
+   For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
 
 ## Troubleshooting
 
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index c77a1a9638f..fdfde22647d 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -343,21 +343,6 @@ world. Custom domains and TLS are supported.
 1. Restart NGINX
 1. [Restart GitLab][restart]
 
-## Change storage path
-
-Follow the steps below to change the default path where GitLab Pages' contents
-are stored.
-
-1. Pages are stored by default in `/var/opt/gitlab/gitlab-rails/shared/pages`.
-   If you wish to store them in another location you must set it up in
-   `/etc/gitlab/gitlab.rb`:
-
-   ```ruby
-   gitlab_rails['pages_path'] = "/mnt/storage/pages"
-   ```
-
-1. [Reconfigure GitLab][reconfigure]
-
 ## NGINX caveats
 
 >**Note:**
@@ -468,7 +453,6 @@ than GitLab to prevent XSS attacks.
 [NGINX configs]: https://gitlab.com/gitlab-org/gitlab-ee/tree/8-5-stable-ee/lib/support/nginx
 [pages-readme]: https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md
 [pages-userguide]: ../../user/project/pages/index.md
-[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
 [restart]: ../restart_gitlab.md#installations-from-source
 [gitlab-pages]: https://gitlab.com/gitlab-org/gitlab-pages/tree/v0.4.0
 [gl-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/init.d/gitlab.default.example
diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md
index ccd9c0afb1d..f8eecc97c33 100644
--- a/doc/administration/raketasks/github_import.md
+++ b/doc/administration/raketasks/github_import.md
@@ -1,6 +1,6 @@
 # GitHub import
 
->  [Introduced]( https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10308) in GitLab 9.1.
+> [Introduced]( https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10308) in GitLab 9.1.
 
 In order to retrieve and import GitHub repositories, you will need a
 [GitHub personal access token](https://github.com/settings/tokens).
diff --git a/doc/administration/raketasks/ldap.md b/doc/administration/raketasks/ldap.md
index e880d76e756..d0ebe272b6d 100644
--- a/doc/administration/raketasks/ldap.md
+++ b/doc/administration/raketasks/ldap.md
@@ -19,8 +19,6 @@ sudo gitlab-rake gitlab:ldap:check
 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:
 
@@ -135,8 +133,6 @@ What is the old provider? Ex. 'ldapmain': ldapmain
 What is the new provider? Ex. 'ldapcustom': ldapmycompany
 ```
 
-------
-
 This tasks also accepts the `force` environment variable which will skip the
 confirmation dialog:
 
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 8d0b5b42515..89335fcd2a8 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -260,7 +260,7 @@ To check the status of migrations, you can use the following rake task:
 sudo gitlab-rake db:migrate:status
 ```
 
-This will output a table with a `Status` of `up` or `down` for 
+This will output a table with a `Status` of `up` or `down` for
 each Migration ID.
 
 ```bash
@@ -269,4 +269,4 @@ database: gitlabhq_production
  Status   Migration ID    Migration Name
 --------------------------------------------------
    up     migration_id    migration_name
-```
\ No newline at end of file
+```
diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md
index 86e8b763f51..d9b4c9b3369 100644
--- a/doc/administration/raketasks/uploads/migrate.md
+++ b/doc/administration/raketasks/uploads/migrate.md
@@ -108,7 +108,7 @@ sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, MergeReque
 
 > Introduced in GitLab 12.3.
 
-To migrate all uploads created by legacy uploaders, run: 
+To migrate all uploads created by legacy uploaders, run:
 
 ```shell
 bundle exec rake gitlab:uploads:legacy:migrate
diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md
index c4a7ba01fae..13b9c30b29d 100644
--- a/doc/administration/troubleshooting/elasticsearch.md
+++ b/doc/administration/troubleshooting/elasticsearch.md
@@ -266,9 +266,9 @@ ElasticSearch administrator.
 
 Generally speaking, ensure:
 
-* The ElasticSearch server **is not** running on the same node as GitLab.
-* The ElasticSearch server have enough RAM and CPU cores.
-* That sharding **is** being used.
+- The ElasticSearch server **is not** running on the same node as GitLab.
+- The ElasticSearch server have enough RAM and CPU cores.
+- That sharding **is** being used.
 
 Going into some more detail here, if ElasticSearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, ElasticSearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
 
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md
index 9b016c64e29..c41edb5dbfc 100644
--- a/doc/administration/troubleshooting/sidekiq.md
+++ b/doc/administration/troubleshooting/sidekiq.md
@@ -96,8 +96,9 @@ corresponding Ruby code where this is happening.
 `gdb` can be another effective tool for debugging Sidekiq. It gives you a little
 more interactive way to look at each thread and see what's causing problems.
 
-> **Note:** Attaching to a process with `gdb` will suspends the normal operation
-  of the process (Sidekiq will not process jobs while `gdb` is attached).
+NOTE: **Note:**
+Attaching to a process with `gdb` will suspends the normal operation
+of the process (Sidekiq will not process jobs while `gdb` is attached).
 
 Start by attaching to the Sidekiq PID:
 
@@ -280,10 +281,10 @@ has number of drawbacks, as mentioned in [Why Ruby’s Timeout is dangerous (and
 
 > This is where the implications get interesting, and terrifying. This means that an exception can get raised:
 >
-> * during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
-> * during the cleanup for the network request
-> * during a rescue block
-> * while creating an object to save to the database afterwards
-> * in any of your code, regardless of whether it could have possibly raised an exception before
+> - during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
+> - during the cleanup for the network request
+> - during a rescue block
+> - while creating an object to save to the database afterwards
+> - in any of your code, regardless of whether it could have possibly raised an exception before
 >
 > Nobody writes code to defend against an exception being raised on literally any line. That’s not even possible. So Thread.raise is  basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that’s unlikely :)