Merge branch 'docs-markdownlint-fixes-1' into 'master'

Fix markdown in various docs (part 1)

See merge request gitlab-org/gitlab-ce!32267

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
 

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.
 

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

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:
 

doc/administration/gitaly/index.md

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

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,7 +105,7 @@ 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
+   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,7 +173,8 @@ 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`,
+   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).
 

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

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:
 

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).
 

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 :)

doc/api/graphql/reference/index.md

@@ -516,4 +516,3 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `username` | String! |  |
 | `avatarUrl` | String! |  |
 | `webUrl` | String! |  |
-

doc/ci/triggers/README.md

@@ -58,8 +58,7 @@ Read more about the [pipelines trigger API][trigapi].
 
 #### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
 
-> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346]
-  in [GitLab Premium][ee] 9.5.
+> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346] in [GitLab Premium][ee] 9.5.
 
 With the introduction of dependencies between different projects, one of
 them may need to access artifacts created by a previous one. This process

doc/development/contributing/index.md

@@ -65,7 +65,7 @@ Sign up for the mailing list, answer GitLab questions on StackOverflow or
 respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with
 the remaining issues on the GitHub issue tracker.
 
-## I want to contribute!
+## I want to contribute
 
 If you want to contribute to GitLab,
 [issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors)

doc/development/documentation/styleguide.md

@@ -783,8 +783,6 @@ For multiple paragraphs, use the symbol `>` before every line:
 >
 > - This is a list item
 > - Second item in the list
->
-> ### This is an `h3`
 ```
 
 Which renders to:
@@ -795,9 +793,6 @@ Which renders to:
 >
 > - This is a list item
 > - Second item in the list
->
-> ### This is an `h3`
->{:.no_toc}
 
 ## Terms
 

doc/development/fe_guide/performance.md

@@ -81,7 +81,7 @@ bundle and included on the page.
 > can find this out by inspecting `document.body.dataset.page` within your
 > browser's developer console while on any page within gitlab.
 
-#### Important Considerations:
+#### Important Considerations
 
 - **Keep Entry Points Lite:**
   Page-specific javascript entry points should be as lite as possible.  These

doc/development/i18n/translation.md

@@ -92,4 +92,3 @@ To propose additions to the glossary please
 In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
 So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
 When space is missing, the male gender should be used alone.
-

doc/development/new_fe_guide/dependencies.md

 # Dependencies
 
-## Adding Dependencies.
+## Adding Dependencies
 
 GitLab uses `yarn` to manage dependencies. These dependencies are defined in
 two groups within `package.json`, `dependencies` and `devDependencies`. For

doc/development/new_fe_guide/development/testing.md

@@ -3,4 +3,3 @@ redirect_to: '../../testing_guide/frontend_testing.md'
 ---
 
 This document was moved to [another location](../../testing_guide/frontend_testing.md).
-

doc/development/testing_guide/end_to_end/quick_start_guide.md

@@ -10,7 +10,7 @@ It's important to understand that end-to-end tests of isolated features, such as
 
 If you don't exactly understand what we mean by **not everything needs to happen through the GUI,** please make sure you've read the [best practices](best_practices.md) before moving on.
 
-## This document covers the following items:
+## This document covers the following items
 
 - [0.](#0-are-end-to-end-tests-needed) Identifying if end-to-end tests are really needed
 - [1.](#1-identifying-the-devops-stage) Identifying the [DevOps stage](https://about.gitlab.com/stages-devops-lifecycle/) of the feature that you are going to cover with end-to-end tests

doc/development/testing_guide/review_apps.md

@@ -132,7 +132,7 @@ to prevent other pods from being scheduled on this node pool.
 This is to ensure Tiller isn't affected by "noisy" neighbors that could put
 their node under pressure.
 
-## How to:
+## How to
 
 ### Log into my Review App
 

doc/development/testing_guide/testing_levels.md

@@ -126,7 +126,7 @@ possible).
 | ---------- | -------------- | ----- |
 | `spec/features/` | [Capybara] + [RSpec] | If your test has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. |
 
-### Consider **not** writing a system test!
+### Consider **not** writing a system test
 
 If we're confident that the low-level components work well (and we should be if
 we have enough Unit & Integration tests), we shouldn't need to duplicate their