Add Markdown linting

Also adds and one linting rule
and makes project conform to it.

9 files changed, 75 insertions, 53 deletions

diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index f7f36901fe1..2ed2a905db7 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -198,9 +198,9 @@ abilities as in the Rails app.
 If the:
 
 - Currently authenticated user fails the authorization, the authorized
-resource will be returned as `null`.
+  resource will be returned as `null`.
 - Resource is part of a collection, the collection will be filtered to
-exclude the objects that the user's authorization checks failed against.
+  exclude the objects that the user's authorization checks failed against.
 
 TIP: **Tip:**
 Try to load only what the currently authenticated user is allowed to
@@ -496,4 +496,4 @@ it 'returns a successful response' do
    expect(response).to have_gitlab_http_status(:success)
    expect(graphql_mutation_response(:merge_request_set_wip)['errors']).to be_empty
 end
-```
\ No newline at end of file
+```
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 8a4aa5dfa7f..6064f59ed10 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -126,16 +126,16 @@ When writing commit messages, please follow the guidelines below:
 
 - The commit subject must contain at least 3 words.
 - The commit subject should ideally contain up to 50 characters,
-and must not be longer than 72 characters.
+  and must not be longer than 72 characters.
 - The commit subject must start with a capital letter.
 - The commit subject must not end with a period.
 - The commit subject and body must be separated by a blank line.
 - The commit body must not contain more than 72 characters per line.
 - Commits that change 30 or more lines across at least 3 files must
-describe these changes in the commit body.
+  describe these changes in the commit body.
 - The commit subject or body must not contain Emojis.
 - Use issues and merge requests' full URLs instead of short references,
-as they are displayed as plain text outside of GitLab.
+  as they are displayed as plain text outside of GitLab.
 - The merge request must not contain more than 10 commit messages.
 
 If the guidelines are not met, the MR will not pass the
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index c7fa40af930..418e58b22d5 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -76,10 +76,10 @@ After a given documentation path is aligned across CE and EE, all merge requests
 affecting that path must be submitted to CE, regardless of the content it has.
 This means that:
 
-* For **EE-only docs changes**, you only have to submit a CE MR.
-* For **EE-only features** that touch both the code and the docs, you have to submit
-an EE MR containing all changes, and a CE MR containing only the docs changes
-and without a changelog entry.
+- For **EE-only docs changes**, you only have to submit a CE MR.
+- For **EE-only features** that touch both the code and the docs, you have to submit
+  an EE MR containing all changes, and a CE MR containing only the docs changes
+  and without a changelog entry.
 
 This might seem like a duplicate effort, but it's only for the short term.
 A list of the already aligned docs can be found in
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index b8506a72666..23d52a33881 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -165,8 +165,8 @@ The table below shows what kind of documentation goes where.
    `doc/topics/topic-name/subtopic-name/index.md` when subtopics become necessary.
    General user- and admin- related documentation, should be placed accordingly.
 1. The directories `/workflow/`, `/university/`, and `/articles/` have
-been **deprecated** and the majority their docs have been moved to their correct location
-in small iterations.
+   been **deprecated** and the majority their docs have been moved to their correct location
+   in small iterations.
 
 If you are unsure where a document or a content addition should live, this should
 not stop you from authoring and contributing. You can use your best judgment and
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index cca52706ddc..6b416cf588c 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -909,11 +909,12 @@ import bundle from 'ee_else_ce/protected_branches/protected_branches_bundle.js';
 See the frontend guide [performance section](fe_guide/performance.md) for
 information on managing page-specific javascript within EE.
 
-
 ## Vue code in `assets/javascript`
+
 ### script tag
 
 #### Child Component only used in EE
+
 To separate Vue template differences we should [async import the components](https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components).
 
 Doing this allows for us to load the correct component in EE whilst in CE
@@ -937,10 +938,12 @@ export default {
 ```
 
 #### For JS code that is EE only, like props, computed properties, methods, etc, we will keep the current approach
- - Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) alias we already have for webpack.
+
+- Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) alias we already have for webpack.
   - This means all the EE specific props, computed properties, methods, etc that are EE only should be in a mixin in the `ee/` folder and we need to create a CE counterpart of the mixin
 
 ##### Example:
+
 ```javascript
 import mixin from 'ee_else_ce/path/mixin';
 
@@ -955,6 +958,7 @@ import mixin from 'ee_else_ce/path/mixin';
 - You can see an MR with an example [here](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9762)
 
 #### `template` tag
+
 * **EE Child components**
   - Since we are using the async loading to check which component to load, we'd still use the component's name, check [this example](#child-component-only-used-in-ee).
 
@@ -962,11 +966,12 @@ import mixin from 'ee_else_ce/path/mixin';
   - For the templates that have extra HTML in EE we should move it into a new component and use the `ee_else_ce` dynamic import
 
 ### Non Vue Files
+
 For regular JS files, the approach is similar.
 
 1. We will keep using the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) helper, this means that EE only code should be inside the `ee/` folder.
-  1. An EE file should be created with the EE only code, and it should extend the CE counterpart.
-  1. For code inside functions that can't be extended, the code should be moved into a new file and we should use `ee_else_ce` helper:
+   1. An EE file should be created with the EE only code, and it should extend the CE counterpart.
+   1. For code inside functions that can't be extended, the code should be moved into a new file and we should use `ee_else_ce` helper:
 
 ##### Example:
 
@@ -996,6 +1001,7 @@ to isolate such ruleset from rest of CE rules (along with adding comment describ
 to avoid conflicts during CE to EE merge.
 
 #### Bad
+
 ```scss
 .section-body {
   .section-title {
@@ -1011,6 +1017,7 @@ to avoid conflicts during CE to EE merge.
 ```
 
 #### Good
+
 ```scss
 .section-body {
   .section-title {
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index c8c70fa7216..94b3796f6e9 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -64,20 +64,25 @@ All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq j
 Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
 
 ## Existing Analyzers/Tokenizers/Filters
+
 These are all defined in https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/lib/elasticsearch/git/model.rb
 
 ### Analyzers
+
 #### `path_analyzer`
+
 Used when indexing blobs' paths. Uses the `path_tokenizer` and the `lowercase` and `asciifolding` filters.
 
 Please see the `path_tokenizer` explanation below for an example.
 
 #### `sha_analyzer`
+
 Used in blobs and commits. Uses the `sha_tokenizer` and the `lowercase` and `asciifolding` filters.
 
 Please see the `sha_tokenizer` explanation later below for an example.
 
 #### `code_analyzer`
+
 Used when indexing a blob's filename and content. Uses the `whitespace` tokenizer and the filters: `code`, `edgeNGram_filter`, `lowercase`, and `asciifolding`
 
 The `whitespace` tokenizer was selected in order to have more control over how tokens are split. For example the string `Foo::bar(4)` needs to generate tokens like `Foo` and `bar(4)` in order to be properly searched.
@@ -85,15 +90,19 @@ The `whitespace` tokenizer was selected in order to have more control over how t
 Please see the `code` filter for an explanation on how tokens are split.
 
 #### `code_search_analyzer`
+
 Not directly used for indexing, but rather used to transform a search input. Uses the `whitespace` tokenizer and the `lowercase` and `asciifolding` filters.
 
 ### Tokenizers
+
 #### `sha_tokenizer`
+
 This is a custom tokenizer that uses the [`edgeNGram` tokenizer](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/analysis-edgengram-tokenizer.html) to allow SHAs to be searcheable by any sub-set of it (minimum of 5 chars).
 
-example:
+Example:
 
 `240c29dc7e` becomes:
+
 - `240c2`
 - `240c29`
 - `240c29d`
@@ -102,21 +111,26 @@ example:
 - `240c29dc7e`
 
 #### `path_tokenizer`
+
 This is a custom tokenizer that uses the [`path_hierarchy` tokenizer](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/analysis-pathhierarchy-tokenizer.html) with `reverse: true` in order to allow searches to find paths no matter how much or how little of the path is given as input.
 
-example:
+Example:
 
 `'/some/path/application.js'` becomes:
+
 - `'/some/path/application.js'`
 - `'some/path/application.js'`
 - `'path/application.js'`
 - `'application.js'`
 
 ### Filters
+
 #### `code`
-Uses a [Pattern Capture token filter](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/analysis-pattern-capture-tokenfilter.html) to split tokens into more easily searched versions of themselves. 
+
+Uses a [Pattern Capture token filter](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/analysis-pattern-capture-tokenfilter.html) to split tokens into more easily searched versions of themselves.
 
 Patterns:
+
 - `"(\\p{Ll}+|\\p{Lu}\\p{Ll}+|\\p{Lu}+)"`: captures CamelCased and lowedCameCased strings as separate tokens
 - `"(\\d+)"`: extracts digits
 - `"(?=([\\p{Lu}]+[\\p{L}]+))"`: captures CamelCased strings recursively. Ex: `ThisIsATest` => `[ThisIsATest, IsATest, ATest, Test]`
@@ -126,6 +140,7 @@ Patterns:
 - `'\/?([^\/]+)(?=\/|\b)'`: separate path terms `like/this/one`
 
 #### `edgeNGram_filter`
+
 Uses an [Edge NGram token filter](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/analysis-edgengram-tokenfilter.html) to allow inputs with only parts of a token to find the token. For example it would turn `glasses` into permutations starting with `gl` and ending with `glasses`, which would allow a search for "`glass`" to find the original token `glasses`
 
 ## Gotchas
@@ -140,13 +155,13 @@ Uses an [Edge NGram token filter](https://www.elastic.co/guide/en/elasticsearch/
 You might get an error such as
 
 ```
-[2018-10-31T15:54:19,762][WARN ][o.e.c.r.a.DiskThresholdMonitor] [pval5Ct] 
-   flood stage disk watermark [95%] exceeded on 
-   [pval5Ct7SieH90t5MykM5w][pval5Ct][/usr/local/var/lib/elasticsearch/nodes/0] free: 56.2gb[3%], 
+[2018-10-31T15:54:19,762][WARN ][o.e.c.r.a.DiskThresholdMonitor] [pval5Ct]
+   flood stage disk watermark [95%] exceeded on
+   [pval5Ct7SieH90t5MykM5w][pval5Ct][/usr/local/var/lib/elasticsearch/nodes/0] free: 56.2gb[3%],
    all indices on this node will be marked read-only
 ```
 
-This is because you've exceeded the disk space threshold - it thinks you don't have enough disk space left, based on the default 95% threshold.  
+This is because you've exceeded the disk space threshold - it thinks you don't have enough disk space left, based on the default 95% threshold.
 
 In addition, the `read_only_allow_delete` setting will be set to `true`.  It will block indexing, `forcemerge`, etc
 
@@ -158,16 +173,16 @@ Add this to your `elasticsearch.yml` file:
 
 ```
 # turn off the disk allocator
-cluster.routing.allocation.disk.threshold_enabled: false 
+cluster.routing.allocation.disk.threshold_enabled: false
 ```
 
 _or_
 
 ```
 # set your own limits
-cluster.routing.allocation.disk.threshold_enabled: true 
+cluster.routing.allocation.disk.threshold_enabled: true
 cluster.routing.allocation.disk.watermark.flood_stage: 5gb   # ES 6.x only
-cluster.routing.allocation.disk.watermark.low: 15gb 
+cluster.routing.allocation.disk.watermark.low: 15gb
 cluster.routing.allocation.disk.watermark.high: 10gb
 ```
 
diff --git a/doc/development/geo.md b/doc/development/geo.md
index 6e59fab34c7..a10f13b069f 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -14,10 +14,10 @@ Geo handles replication for different components:
 - [Database](#database-replication): includes the entire application, except cache and jobs.
 - [Git repositories](#repository-replication): includes both projects and wikis.
 - [Uploaded blobs](#uploads-replication): includes anything from images attached on issues
-to raw logs and assets from CI.
+  to raw logs and assets from CI.
 
 With the exception of the Database replication, on a *secondary* node, everything is coordinated
-by the [Geo Log Cursor](#geo-log-cursor). 
+by the [Geo Log Cursor](#geo-log-cursor).
 
 ### Geo Log Cursor daemon
 
@@ -31,8 +31,8 @@ picks the event up and schedules a `Geo::ProjectSyncWorker` job which will
 use the `Geo::RepositorySyncService` and `Geo::WikiSyncService` classes
 to update the repository and the wiki respectively.
 
-The Geo Log Cursor daemon can operate in High Availability mode automatically. 
-The daemon will try to acquire a lock from time to time and once acquired, it 
+The Geo Log Cursor daemon can operate in High Availability mode automatically.
+The daemon will try to acquire a lock from time to time and once acquired, it
 will behave as the *active* daemon.
 
 Any additional running daemons on the same node, will be in standby
@@ -164,20 +164,20 @@ The Git Push Proxy exists as a functionality built inside the `gitlab-shell` com
 It is active on a **secondary** node only. It allows the user that has cloned a repository
 from the secondary node to push to the same URL.
 
-Git `push` requests directed to a **secondary** node will be sent over to the **primary** node, 
+Git `push` requests directed to a **secondary** node will be sent over to the **primary** node,
 while `pull` requests will continue to be served by the **secondary** node for maximum efficiency.
 
 HTTPS and SSH requests are handled differently:
 
 - With HTTPS, we will give the user a `HTTP 302 Redirect` pointing to the project on the **primary** node.
-The git client is wise enough to understand that status code and process the redirection.
+  The git client is wise enough to understand that status code and process the redirection.
 - With SSH, because there is no equivalent way to perform a redirect, we have to proxy the request.
-This is done inside [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell), by first translating the request 
-to the HTTP protocol, and then proxying it to the **primary** node.
+  This is done inside [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell), by first translating the request
+  to the HTTP protocol, and then proxying it to the **primary** node.
 
-The [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) daemon knows when to proxy based on the response 
-from `/api/v4/allowed`. A special `HTTP 300` status code is returned and we execute a "custom action", 
-specified in the response body. The response contains additional data that allows the proxied `push` operation 
+The [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) daemon knows when to proxy based on the response
+from `/api/v4/allowed`. A special `HTTP 300` status code is returned and we execute a "custom action",
+specified in the response body. The response contains additional data that allows the proxied `push` operation
 to happen on the **primary** node.
 
 ## Using the Tracking Database
@@ -229,17 +229,17 @@ named `gitlab_secondary`. This configuration exists within the database's user
 context only. To access the `gitlab_secondary`, GitLab needs to use the
 same database user that had previously been configured.
 
-The Geo Tracking Database accesses the readonly database replica via FDW as a regular user, 
-limited by its own restrictions. The credentials are configured as a 
-`USER MAPPING` associated with the `SERVER` mapped previously 
+The Geo Tracking Database accesses the readonly database replica via FDW as a regular user,
+limited by its own restrictions. The credentials are configured as a
+`USER MAPPING` associated with the `SERVER` mapped previously
 (`gitlab_secondary`).
 
 FDW configuration and credentials definition are managed automatically by the
-Omnibus GitLab `gitlab-ctl reconfigure` command. 
+Omnibus GitLab `gitlab-ctl reconfigure` command.
 
 #### Refeshing the Foreign Tables
 
-Whenever a new Geo node is configured or the database schema changes on the 
+Whenever a new Geo node is configured or the database schema changes on the
 **primary** node, you must refresh the foreign tables on the **secondary** node
 by running the following:
 
@@ -279,11 +279,11 @@ on the Tracking Database:
 SELECT project_registry.*
   FROM project_registry
   JOIN gitlab_secondary.projects
-    ON (project_registry.project_id = gitlab_secondary.projects.id 
+    ON (project_registry.project_id = gitlab_secondary.projects.id
    AND gitlab_secondary.projects.archived IS FALSE)
 ```
 
-At the ActiveRecord level, we have additional Models that represent the 
+At the ActiveRecord level, we have additional Models that represent the
 foreign tables. They must be mapped in a slightly different way, and they are read-only.
 
 Check the existing FDW models in `ee/app/models/geo/fdw` for reference.
diff --git a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
index f7b3ca8bc89..aec0a3ede5a 100644
--- a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
+++ b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
@@ -5,8 +5,8 @@ We devised a solution to solve common test automation problems such as the dread
 Other problems that dynamic element validations solve are...
 
 - When we perform an action with the mouse, we expect something to occur.
-- When our test is navigating to (or from) a page, we ensure that we are on the page we expect before 
-test continuation.
+- When our test is navigating to (or from) a page, we ensure that we are on the page we expect before
+  test continuation.
 
 ## How it works
 
@@ -19,7 +19,7 @@ We interpret user actions on the page to have some sort of effect. These actions
 
 When a page is navigated to, there are elements that will always appear on the page unconditionally.
 
-Dynamic element validation is instituted when using 
+Dynamic element validation is instituted when using
 
 ```ruby
 Runtime::Browser.visit(:gitlab, Some::Page)
@@ -27,7 +27,7 @@ Runtime::Browser.visit(:gitlab, Some::Page)
 
 ### Clicks
 
-When we perform a click within our tests, we expect something to occur.  That something could be a component to now 
+When we perform a click within our tests, we expect something to occur.  That something could be a component to now
 appear on the webpage, or the test to navigate away from the page entirely.
 
 Dynamic element validation is instituted when using
@@ -71,7 +71,7 @@ class MyPage < Page::Base
     element :another_element, required: true
     element :conditional_element
   end
-  
+
   def open_layer
     click_element :my_element, Layer::MyLayer
   end
@@ -95,7 +95,7 @@ execute_stuff
 ```
 
 will invoke GitLab QA to scan `MyPage` for `my_element` and `another_element` to be on the page before continuing to
-`execute_stuff` 
+`execute_stuff`
 
 ### Clicking
 
diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md
index 73e1fd862c1..05cb03eb4bd 100644
--- a/doc/development/testing_guide/end_to_end/page_objects.md
+++ b/doc/development/testing_guide/end_to_end/page_objects.md
@@ -82,7 +82,7 @@ module Page
       end
 
       # ...
-    end 
+    end
   end
 end
 ```
@@ -134,7 +134,7 @@ for each element defined.
 
 In our case, `qa-login-field`, `qa-password-field` and `qa-sign-in-button`
 
-**app/views/my/view.html.haml**  
+**app/views/my/view.html.haml**
 
 ```haml
 = f.text_field :login, class: "form-control top qa-login-field", autofocus: "autofocus", autocapitalize: "off", autocorrect: "off", required: true, title: "This field is required."
@@ -146,7 +146,7 @@ Things to note:
 
 - The CSS class must be `kebab-cased` (separated with hyphens "`-`")
 - If the element appears on the page unconditionally, add `required: true` to the element. See
-[Dynamic element validation](dynamic_element_validation.md)
+  [Dynamic element validation](dynamic_element_validation.md)
 
 ## Running the test locally