Merge branch 'docs/add-mdl-and-rule-032' into 'master'

Add Markdown linting and one rule

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

.gitlab/ci/docs.gitlab-ci.yml

@@ -66,6 +66,10 @@ docs lint:
     - scripts/lint-changelog-yaml
     - mv doc/ /tmp/gitlab-docs/content/$DOCS_GITLAB_REPO_SUFFIX
     - cd /tmp/gitlab-docs
+    # Lint Markdown
+    # https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
+    - bundle exec mdl content/$DOCS_GITLAB_REPO_SUFFIX/**/*.md --rules \
+        MD032
     # Build HTML from Markdown
     - bundle exec nanoc
     # Check the internal links

doc/administration/auth/oidc.md

@@ -144,20 +144,20 @@ for more details:
 If you're having trouble, here are some tips:
 
 1. Ensure `discovery` is set to `true`. Setting it to `false` requires
-specifying all the URLs and keys required to make OpenID work.
+   specifying all the URLs and keys required to make OpenID work.
 
 1. Check your system clock to ensure the time is synchronized properly.
 
 1. As mentioned in [the
-documentation](https://github.com/m0n9oose/omniauth_openid_connect),
-make sure `issuer` corresponds to the base URL of the Discovery URL. For
-example, `https://accounts.google.com` is used for the URL
-`https://accounts.google.com/.well-known/openid-configuration`.
+   documentation](https://github.com/m0n9oose/omniauth_openid_connect),
+   make sure `issuer` corresponds to the base URL of the Discovery URL. For
+   example, `https://accounts.google.com` is used for the URL
+   `https://accounts.google.com/.well-known/openid-configuration`.
 
 1. The OpenID Connect client uses HTTP Basic Authentication to send the
-OAuth2 access token. For example, if you are seeing 401 errors upon
-retrieving the `userinfo` endpoint, you may want to check your OpenID
-Web server configuration. For example, for
-[oauth2-server-php](https://github.com/bshaffer/oauth2-server-php), you
-may need to [add a configuration parameter to
-Apache](https://github.com/bshaffer/oauth2-server-php/issues/926#issuecomment-387502778).
+   OAuth2 access token. For example, if you are seeing 401 errors upon
+   retrieving the `userinfo` endpoint, you may want to check your OpenID
+   Web server configuration. For example, for
+   [oauth2-server-php](https://github.com/bshaffer/oauth2-server-php), you
+   may need to [add a configuration parameter to
+   Apache](https://github.com/bshaffer/oauth2-server-php/issues/926#issuecomment-387502778).

doc/administration/geo/replication/faq.md

@@ -15,7 +15,7 @@ At the start, this tracking database is empty, so Geo will start trying to updat
 For each project to sync:
 
 1. Geo will issue a `git fetch geo --mirror` to get the latest information from the **primary** node.
-If there are no changes, the sync will be fast and end quickly. Otherwise, it will pull the latest commits.
+   If there are no changes, the sync will be fast and end quickly. Otherwise, it will pull the latest commits.
 1. The **secondary** node will update the tracking database to store the fact that it has synced projects A, B, C, etc.
 1. Repeat until all projects are synced.
 

doc/administration/geo/replication/troubleshooting.md

@@ -331,7 +331,7 @@ There are a few key points to remember:
 
 1. The FDW settings are configured on the Geo **tracking** database.
 1. The configured foreign server enables a login to the Geo
-**secondary**, read-only database.
+   **secondary**, read-only database.
 
 By default, the Geo secondary and tracking database are running on the
 same host on different ports. That is, 5432 and 5431 respectively.
@@ -350,7 +350,7 @@ To check the configuration:
     ```
 
 1. Check whether any tables are present. If everything is working, you
-should see something like this:
+   should see something like this:
 
     ```sql
     gitlabhq_geo_production=# SELECT * from information_schema.foreign_tables;

doc/administration/high_availability/database.md

@@ -204,9 +204,9 @@ Few notes on the service itself:
 
 - The service runs under a system account, by default `gitlab-consul`.
   - If you are using a different username, you will have to specify it. We
-will refer to it with `CONSUL_USERNAME`,
+    will refer to it with `CONSUL_USERNAME`,
 - There will be a database user created with read only access to the repmgr
-database
+  database
 - Passwords will be stored in the following locations:
   - `/etc/gitlab/gitlab.rb`: hashed
   - `/var/opt/gitlab/pgbouncer/pg_auth`: hashed

doc/api/search.md

@@ -346,6 +346,7 @@ Example response:
 This scope is available only if [Elasticsearch](../integration/elasticsearch.md) is enabled.
 
 Filters are available for this scope:
+
 - filename
 - path
 - extension
@@ -679,6 +680,7 @@ Example response:
 This scope is available only if [Elasticsearch](../integration/elasticsearch.md) is enabled.
 
 Filters are available for this scope:
+
 - filename
 - path
 - extension

doc/ci/docker/using_docker_images.md

@@ -489,6 +489,7 @@ it's provided as an environment variable. This is because GitLab Runnner uses **
 runtime.
 
 ### Using statically-defined credentials
+
 As an example, let's assume that you want to use the `registry.example.com:5000/private/image:latest`
 image which is private and requires you to login into a private container registry.
 
@@ -566,7 +567,6 @@ for the Runner to match the `DOCKER_AUTH_CONFIG`. For example, if
 then the `DOCKER_AUTH_CONFIG` must also specify `registry.example.com:5000`.
 Specifying only `registry.example.com` will not work.
 
-
 ### Using Credentials Store
 
 > Support for using Credentials Store was added in GitLab Runner 9.5.
@@ -574,7 +574,7 @@ Specifying only `registry.example.com` will not work.
 To configure credentials store, follow these steps:
 
 1. To use a credentials store, you need an external helper program to interact with a specific keychain or external store.
-Make sure helper program is available in GitLab Runner `$PATH`.
+   Make sure helper program is available in GitLab Runner `$PATH`.
 
 1. Make GitLab Runner use it. There are two ways to accomplish this. Either:
    - Create a

doc/ci/examples/test-scala-application.md

@@ -47,10 +47,10 @@ deploy:
 In the above configuration:
 
 - The `before_script` installs [SBT](http://www.scala-sbt.org/) and
-displays the version that is being used.
+  displays the version that is being used.
 - The `test` stage executes SBT to compile and test the project.
   - [sbt-scoverage](https://github.com/scoverage/sbt-scoverage) is used as an SBT
-plugin to measure test coverage.
+    plugin to measure test coverage.
 - The `deploy` stage automatically deploys the project to Heroku using dpl.
 
 You can use other versions of Scala and SBT by defining them in

doc/ci/variables/README.md

@@ -339,7 +339,7 @@ Group-level variables can be added by:
 
 1. Navigating to your group's **Settings > CI/CD** page.
 1. Inputing variable types, keys, and values in the **Variables** section.
-Any variables of [subgroups](../../user/group/subgroups/index.md) will be inherited recursively.
+   Any variables of [subgroups](../../user/group/subgroups/index.md) will be inherited recursively.
 
 Once you set them, they will be available for all subsequent pipelines.
 

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

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

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

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

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,6 +966,7 @@ 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.
@@ -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 {

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

doc/development/geo.md

@@ -14,7 +14,7 @@ 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).
@@ -170,10 +170,10 @@ while `pull` requests will continue to be served by the **secondary** node for m
 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",

doc/development/testing_guide/end_to_end/dynamic_element_validation.md

@@ -6,7 +6,7 @@ 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.
+  test continuation.
 
 ## How it works
 

doc/development/testing_guide/end_to_end/page_objects.md

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

doc/integration/jenkins.md

@@ -25,22 +25,22 @@ and [Migrating from Jenkins to GitLab](https://www.youtube.com/watch?v=RlEVGOpYF
 ## Use cases
 
 - Suppose you are new to GitLab, and want to keep using Jenkins until you prepare
-your projects to build with [GitLab CI/CD](../ci/README.md). You set up the
-integration between GitLab and Jenkins, then you migrate to GitLab CI later. While
-you organize yourself and your team to onboard GitLab, you keep your pipelines
-running with Jenkins, but view the results in your project's repository in GitLab.
+  your projects to build with [GitLab CI/CD](../ci/README.md). You set up the
+  integration between GitLab and Jenkins, then you migrate to GitLab CI later. While
+  you organize yourself and your team to onboard GitLab, you keep your pipelines
+  running with Jenkins, but view the results in your project's repository in GitLab.
 - Your team uses [Jenkins Plugins](https://plugins.jenkins.io/) for other proceedings,
-therefore, you opt for keep using Jenkins to build your apps. Show the results of your
-pipelines directly in GitLab.
+  therefore, you opt for keep using Jenkins to build your apps. Show the results of your
+  pipelines directly in GitLab.
 
 For a real use case, read the blog post [Continuous integration: From Jenkins to GitLab using Docker](https://about.gitlab.com/2017/07/27/docker-my-precious/).
 
 ## Requirements
 
-* [Jenkins GitLab Plugin](https://wiki.jenkins.io/display/JENKINS/GitLab+Plugin)
-* [Jenkins Git Plugin](https://wiki.jenkins.io/display/JENKINS/Git+Plugin)
-* Git clone access for Jenkins from the GitLab repository
-* GitLab API access to report build status
+- [Jenkins GitLab Plugin](https://wiki.jenkins.io/display/JENKINS/GitLab+Plugin)
+- [Jenkins Git Plugin](https://wiki.jenkins.io/display/JENKINS/Git+Plugin)
+- Git clone access for Jenkins from the GitLab repository
+- GitLab API access to report build status
 
 ## Configure GitLab users
 
@@ -114,9 +114,9 @@ and storing build status for Commits and Merge Requests.
 All steps are implemented using AJAX requests on the merge request page.
 
 1. In order to display the build status in a merge request you must create a project service in GitLab.
-2. Your project service will do a (JSON) query to a URL of the CI tool with the SHA1 of the commit.
-3. The project service builds this URL and payload based on project service settings and knowledge of the CI tool.
-4. The response is parsed to give a response in GitLab (success/failed/pending).
+1. Your project service will do a (JSON) query to a URL of the CI tool with the SHA1 of the commit.
+1. The project service builds this URL and payload based on project service settings and knowledge of the CI tool.
+1. The response is parsed to give a response in GitLab (success/failed/pending).
 
 ## Troubleshooting
 
@@ -130,5 +130,5 @@ receive a build status update via the API. Either Jenkins was not properly
 configured or there was an error reporting the status via the API.
 
 1. [Configure the Jenkins server](#configure-the-jenkins-server) for GitLab API access
-2. [Configure a Jenkins project](#configure-a-jenkins-project), including the 
+1. [Configure a Jenkins project](#configure-a-jenkins-project), including the
    'Publish build status to GitLab' post-build action.

doc/subscriptions/index.md

@@ -74,9 +74,9 @@ Please note that you need to be a group owner to associate a group to your subsc
 To see the status of your GitLab.com subscription, you can click on the Billings
 section of the relevant namespace:
 
-* For individuals, this is located at https://gitlab.com/profile/billings under
-in your Settings,
-* For groups, this is located under the group's Settings dropdown, under Billing.
+- For individuals, this is located at https://gitlab.com/profile/billings under
+  in your Settings,
+- For groups, this is located under the group's Settings dropdown, under Billing.
 
 For groups, you can see details of your subscription - including your current
 plan - in the included table:

doc/user/admin_area/index.md

@@ -186,7 +186,7 @@ the sort order to *Last Contacted* from the dropdown beside the search field.
 To search Runners' descriptions:
 
 1. In the **Search or filter results...** field, type the description of the Runner you want to
-find.
+   find.
 1. Press Enter.
 
 You can also filter Runners by status, type, and tag. To filter:

doc/user/admin_area/settings/continuous_integration.md

@@ -94,7 +94,6 @@ a group in the **Usage Quotas** page available to the group page settings list.
 
 ![Group pipelines quota](img/group_pipelines_quota.png)
 
-
 ## Extra Shared Runners pipeline minutes quota
 
 NOTE: **Note:**
@@ -110,27 +109,27 @@ In order to purchase additional minutes, you should follow these steps:
     ![Buy additional minutes](img/buy_btn.png)
 
 1. Locate the subscription card that is linked to your group on GitLab.com,
-click on **Buy more CI minutes**, and complete the details about the transaction.
+   click on **Buy more CI minutes**, and complete the details about the transaction.
 
     ![Buy additional minutes](img/buy_minutes_card.png)
 
 1. Once we have processed your payment, the extra CI minutes
-will be synced to your Group and you can visualize it from  the
-**Group > Settings > Pipelines quota** page:
+   will be synced to your Group and you can visualize it from  the
+   **Group > Settings > Pipelines quota** page:
 
     ![Additional minutes](img/additional_minutes.png)
 
 Be aware that:
 
 1. If you have purchased extra CI minutes before the purchase of a paid plan,
-we will calculate a pro-rated charge for your paid plan. That means you may
-be charged for less than one year since your subscription was previously
-created with the extra CI minutes.
+   we will calculate a pro-rated charge for your paid plan. That means you may
+   be charged for less than one year since your subscription was previously
+   created with the extra CI minutes.
 1. Once the extra CI minutes has been assigned to a Group they cannot be transferred
-to a different Group.
+   to a different Group.
 1. If you have some minutes used over your default quota, these minutes will
-be deducted from your Additional Minutes quota immediately after your purchase of additional
-minutes.
+   be deducted from your Additional Minutes quota immediately after your purchase of additional
+   minutes.
 
 ## What happens when my CI minutes quota run out
 

doc/user/admin_area/settings/terms.md

@@ -17,7 +17,7 @@ To enforce acceptance of a Terms of Service and Privacy Policy:
 1. Go to **Admin Area > Settings > General**.
 1. Expand the **Terms of Service and Privacy Policy** section.
 1. Check the **Require all users to accept Terms of Service and Privacy Policy when they access
-GitLab.** checkbox.
+   GitLab.** checkbox.
 1. Input the text of the **Terms of Service and Privacy Policy**. Markdown formatting can be used in this input box.
 1. Click **Save changes**.
 1. When you are presented with the **Terms of Service** statement, click **Accept terms**.

doc/user/group/contribution_analytics/index.md

@@ -21,9 +21,9 @@ page.
 ## Use cases
 
 - Analyze your team's contributions over a period of time, and offer a bonus for the top
-contributors.
+  contributors.
 - Identify opportunities for improvement with group members who may benefit from additional
-support.
+  support.
 
 ## Using Contribution Analytics
 

doc/user/group/epics/index.md

@@ -202,8 +202,8 @@ You may also consult the [group permissions table][permissions].
 ## Thread
 
 - Comments: collaborate on that epic by posting comments in its thread.
-These text fields also fully support
-[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
+  These text fields also fully support
+  [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
 
 ## Comment, or start a discussion
 

doc/user/group/index.md

@@ -41,11 +41,12 @@ You can create groups for numerous reasons. To name a couple:
 - Make it easier to `@mention` all of your team at once in issues and merge requests by creating a group and including the appropriate members.
 
 For example, you could create a group for your company members, and create a [subgroup](subgroups/index.md) for each individual team. Let's say you create a group called `company-team`, and you create subgroups in this group for the individual teams `backend-team`, `frontend-team`, and `production-team`.
-    - When you start a new implementation from an issue, you add a comment:
+
+- When you start a new implementation from an issue, you add a comment:
   _"`@company-team`, let's do it! `@company-team/backend-team` you're good to go!"_
-    - When your backend team needs help from frontend, they add a comment:
+- When your backend team needs help from frontend, they add a comment:
   _"`@company-team/frontend-team` could you help us here please?"_
-    - When the frontend team completes their implementation, they comment:
+- When the frontend team completes their implementation, they comment:
   _"`@company-team/backend-team`, it's done! Let's ship it `@company-team/production-team`!"_
 
 ## Namespaces

doc/user/group/saml_sso/scim_setup.md

@@ -69,9 +69,9 @@ The GitLab app in Azure needs to be configured following
 Note the following:
 
 - The `Tenant URL` and `secret token` are the ones retrieved in the
-[previous step](#gitlab-configuration).
+  [previous step](#gitlab-configuration).
 - Should there be any problems with the availability of GitLab or similar
-errors, the notification email set will get those.
+  errors, the notification email set will get those.
 - For mappings, we will only leave `Synchronize Azure Active Directory Users to AppName` enabled.
 
 You can then test the connection clicking on `Test Connection`.
@@ -79,11 +79,11 @@ You can then test the connection clicking on `Test Connection`.
 ### Synchronize Azure Active Directory users
 
 1. Click on `Synchronize Azure Active Directory Users to AppName`, to configure
-the attribute mapping.
+   the attribute mapping.
 1. Select the unique identifier (in the example `objectId`) as the `id` and `externalId`,
-and enable the `Create`, `Update`, and `Delete` actions.
+   and enable the `Create`, `Update`, and `Delete` actions.
 1. Map the `userPricipalName` to `emails[type eq "work"].value` and `mailNickname` to
-`userName`.
+   `userName`.
 
     Example configuration:
 
@@ -99,7 +99,7 @@ and enable the `Create`, `Update`, and `Delete` actions.
     ![Azure's attribute advanced configuration](img/scim_advanced.png)
 
 1. Save all the screens and, in the **Provisioning** step, set
-the `Provisioning Status` to `ON`.
+   the `Provisioning Status` to `ON`.
 
     NOTE: **Note:**
     You can control what is actually synced by selecting the `Scope`. For example,

doc/user/project/clusters/kubernetes_pod_logs.md

@@ -12,9 +12,9 @@ By displaying the logs directly in GitLab, developers can avoid having to manage
 1. Go to **Operations > Environments** and find the environment which contains the desired pod, like `production`.
 1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md).
 1. When mousing over the list of pods, a tooltip will appear with the exact pod name and status.
-![Deploy Boards pod list](img/pod_logs_deploy_board.png)
+   ![Deploy Boards pod list](img/pod_logs_deploy_board.png)
 1. Click on the desired pod to bring up the logs view, which will contain the last 500 lines for that pod. Support for pods with multiple containers is coming [in a future release](https://gitlab.com/gitlab-org/gitlab-ee/issues/6502).
-![Deploy Boards pod list](img/kubernetes_pod_logs.png)
+   ![Deploy Boards pod list](img/kubernetes_pod_logs.png)
 
 ## Requirements
 

doc/user/project/description_templates.md

@@ -25,14 +25,14 @@ templates of the default branch will be taken into account.
 ## Use-cases
 
 - Add a template to be used in every issue for a specific project,
-giving instructions and guidelines, requiring for information specific to that subject.
-For example, if you have a project for tracking new blog posts, you can require the
-title, outlines, author name, author social media information, etc.
+  giving instructions and guidelines, requiring for information specific to that subject.
+  For example, if you have a project for tracking new blog posts, you can require the
+  title, outlines, author name, author social media information, etc.
 - Following the previous example, you can make a template for every MR submitted
-with a new blog post, requiring information about the post date, frontmatter data,
-images guidelines, link to the related issue, reviewer name, etc.
+  with a new blog post, requiring information about the post date, frontmatter data,
+  images guidelines, link to the related issue, reviewer name, etc.
 - You can also create issues and merge request templates for different
-stages of your workflow, e.g., feature proposal, feature improvement, bug report, etc.
+  stages of your workflow, e.g., feature proposal, feature improvement, bug report, etc.
 
 ## Creating issue templates
 

doc/user/project/integrations/hipchat.md

@@ -23,7 +23,7 @@ allow GitLab to send messages only to *one* room.
 1. Find "Build Your Own!" and click "Create".
 1. Select the desired room, name the integration "GitLab", and click "Create".
 1. In the "Send messages to this room by posting this URL" column, you should
-see a URL in the format:
+   see a URL in the format:
 
 ```
 https://api.hipchat.com/v2/room/<room>/notification?auth_token=<token>

doc/user/project/issues/index.md

@@ -134,4 +134,4 @@ For more information, see [Crosslinking issues](crosslinking_issues.md).
 - [Export issues](csv_export.md) **[STARTER]**
 - [Issues API](../../../api/issues.md)
 - Configure an [external issue tracker](../../../integration/external-issue-tracker.md) such as Jira, Redmine,
-or Bugzilla.
+  or Bugzilla.

doc/user/project/merge_requests/merge_request_approvals.md

@@ -12,9 +12,9 @@ to approve a merge request before it can be unblocked for merging.
 ## Use cases
 
 1. Enforcing review of all code that gets merged into a repository.
-2. Specifying code maintainers for an entire repository.
-3. Specifying reviewers for a given proposed code change.
-4. Specifying categories of reviewers, such as BE, FE, QA, DB, etc., for all proposed code changes.
+1. Specifying code maintainers for an entire repository.
+1. Specifying reviewers for a given proposed code change.
+1. Specifying categories of reviewers, such as BE, FE, QA, DB, etc., for all proposed code changes.
 
 ## Enabling the new approvals interface
 
@@ -246,7 +246,7 @@ restrictions (compared to [GitLab Starter](#overriding-the-merge-request-approva
 - Approval rules can be added to an MR with no restriction.
 - For project sourced approval rules, editing and removing approvers is not allowed.
 - The approvals required of all approval rules is configurable, but if a rule is backed by a project rule, then it is restricted
-to the minimum approvals required set in the project's corresponding rule.
+  to the minimum approvals required set in the project's corresponding rule.
 
 ## Resetting approvals on push
 

doc/user/project/pages/getting_started_part_two.md

@@ -77,10 +77,10 @@ containing the most popular SSGs templates to get you started.
 
 1. [Fork](../../../gitlab-basics/fork-project.md) a sample project from the [GitLab Pages examples](https://gitlab.com/pages) group.
 1. From the left sidebar, navigate to your project's **CI/CD > Pipelines**
-and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your
-site to the server.
+   and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your
+   site to the server.
 1. Once the pipeline has finished successfully, find the link to visit your
-website from your project's **Settings > Pages**.
+   website from your project's **Settings > Pages**.
 
 You can also take some **optional** further steps:
 
@@ -89,7 +89,7 @@ You can also take some **optional** further steps:
     ![remove fork relationship](img/remove_fork_relationship.png)
 
 - _Make it a user or group website._ To turn a **project website** forked
-from the Pages group into a **user/group** website, you'll need to:
+  from the Pages group into a **user/group** website, you'll need to:
     - Rename it to `namespace.gitlab.io`: go to your project's
       **Settings > General** and expand **Advanced**. Scroll down to
       **Rename repository** and change the path to `namespace.gitlab.io`.

doc/user/project/pages/index.md

@@ -12,7 +12,6 @@ type: index, reference
 > - Support for subgroup project's websites was [introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) in GitLab 11.8.
 > - Bundled project templates were [introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/47857) in GitLab 11.8.
 
-
 **GitLab Pages is a feature that allows you to publish static websites
 directly from a repository in GitLab.**
 
@@ -105,10 +104,10 @@ To get started with GitLab Pages, you can either:
     ![Project templates for Pages](img/pages_project_templates_11-8.png)
 
 1. From the left sidebar, navigate to your project's **CI/CD > Pipelines**
-and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your
-site to the server.
+   and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your
+   site to the server.
 1. Once the pipeline has finished successfully, find the link to visit your
-website from your project's **Settings > Pages**.
+   website from your project's **Settings > Pages**.
 
 Your website is then visible on your domain, and you can modify yourfiles
 as you wish. For every modification pushed to your repository, GitLab CI/CD

doc/user/project/pages/introduction.md

@@ -13,17 +13,17 @@ To familiarize yourself with GitLab Pages first:
 - Read an [introduction to GitLab Pages](index.md#overview).
 - Learn [how to get started with Pages](index.md#getting-started).
 - Learn how to enable GitLab Pages
-across your GitLab instance on the [administrator documentation](../../../administration/pages/index.md).
+  across your GitLab instance on the [administrator documentation](../../../administration/pages/index.md).
 
 ## GitLab Pages requirements
 
 In brief, this is what you need to upload your website in GitLab Pages:
 
 1. Domain of the instance: domain name that is used for GitLab Pages
-(ask your administrator).
+   (ask your administrator).
 1. GitLab CI/CD: a `.gitlab-ci.yml` file with a specific job named [`pages`][pages] in the root directory of your repository.
 1. A directory called `public` in your site's repo containing the content
-to be published.
+   to be published.
 1. GitLab Runner enabled for the project.
 
 ## GitLab Pages on GitLab.com

doc/user/project/settings/index.md

@@ -109,8 +109,8 @@ You can transfer an existing project into a [group](../../group/index.md) if:
 1. You have at least **Maintainer** [permissions] to that group.
 1. The project is in a subgroup you own.
 1. You are at least a **Maintainer** of the project under your personal namespace.
-Similarly, if you are an owner of a group, you can transfer any of its projects
-under your own user.
+   Similarly, if you are an owner of a group, you can transfer any of its projects
+   under your own user.
 
 To transfer a project:
 

doc/user/project/web_ide/index.md

@@ -171,13 +171,13 @@ syntax but with some restrictions:
 - No global blocks can be defined (ie: `before_script` or `after_script`)
 - Only one job named `terminal` can be added to this file.
 - Only the keywords `image`, `services`, `tags`, `before_script`, `script`, and
-`variables` are allowed to be used to configure the job.
+  `variables` are allowed to be used to configure the job.
 - To connect to the interactive terminal, the `terminal` job must be still alive
-and running, otherwise the terminal won't be able to connect to the job's session.
-By default the `script` keyword has the value `sleep 60` to prevent
-the job from ending and giving the Web IDE enough time to connect. This means
-that, if you override the default `script` value, you'll have to add a command
-which would keep the job running, like `sleep`.
+  and running, otherwise the terminal won't be able to connect to the job's session.
+  By default the `script` keyword has the value `sleep 60` to prevent
+  the job from ending and giving the Web IDE enough time to connect. This means
+  that, if you override the default `script` value, you'll have to add a command
+  which would keep the job running, like `sleep`.
 
 In the code below there is an example of this configuration file: