Resolve "CE documentation is not CommonMark compliant"

doc/administration/auth/ldap.md

@@ -390,7 +390,7 @@ the configuration option `lowercase_usernames`. By default, this configuration o
     EOS
     ```
 
-2. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 **Source configuration**
 
@@ -404,7 +404,8 @@ the configuration option `lowercase_usernames`. By default, this configuration o
             # snip...
             lowercase_usernames: true
     ```
-2. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+
+1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 ## Encryption
 

doc/administration/container_registry.md

 # GitLab Container Registry administration
 
 > **Notes:**
-- [Introduced][ce-4040] in GitLab 8.8.
-- Container Registry manifest `v1` support was added in GitLab 8.9 to support
-  Docker versions earlier than 1.10.
-- This document is about the admin guide. To learn how to use GitLab Container
-  Registry [user documentation](../user/project/container_registry.md).
+> - [Introduced][ce-4040] in GitLab 8.8.
+> - Container Registry manifest `v1` support was added in GitLab 8.9 to support
+>   Docker versions earlier than 1.10.
+> - This document is about the admin guide. To learn how to use GitLab Container
+>   Registry [user documentation](../user/project/container_registry.md).
 
 With the Container Registry integrated into GitLab, every project can have its
 own space to store its Docker images.
@@ -203,10 +203,10 @@ If you have a [wildcard certificate][], you need to specify the path to the
 certificate in addition to the URL, in this case `/etc/gitlab/gitlab.rb` will
 look like:
 >
-```ruby
-registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/certificate.pem"
-registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
-```
+> ```ruby
+> registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/certificate.pem"
+> registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
+> ```
 
 ---
 
@@ -375,7 +375,7 @@ Read more about the individual driver's config options in the
 > **Warning** GitLab will not backup Docker images that are not stored on the
 filesystem. Remember to enable backups with your object storage provider if
 desired.
-
+> 
 > **Important** Enabling storage driver other than `filesystem` would mean
 that your Docker client needs to be able to access the storage backend directly.
 So you must use an address that resolves and is accessible outside GitLab server.
@@ -598,11 +598,11 @@ thus the error above.
 
 While GitLab doesn't support using self-signed certificates with Container
 Registry out of the box, it is possible to make it work if you follow
-[Docker's documentation][docker-insecure]. You may find some additional
+[Docker's documentation][docker-insecure-self-signed]. You may find some additional
 information in [issue 18239][ce-18239].
 
 [ce-18239]: https://gitlab.com/gitlab-org/gitlab-ce/issues/18239
-[docker-insecure]: https://docs.docker.com/registry/insecure/#using-self-signed-certificates
+[docker-insecure-self-signed]: https://docs.docker.com/registry/insecure/#use-self-signed-certificates
 [reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure
 [restart gitlab]: restart_gitlab.md#installations-from-source
 [wildcard certificate]: https://en.wikipedia.org/wiki/Wildcard_certificate

doc/administration/custom_hooks.md

 # Custom Git Hooks
 
->
-**Note:** Custom Git hooks must be configured on the filesystem of the GitLab
+> **Note:** Custom Git hooks must be configured on the filesystem of the GitLab
 server. Only GitLab server administrators will be able to complete these tasks.
 Please explore [webhooks] and [CI] as an option if you do not
 have filesystem access. For a user configurable Git hook interface, see

doc/administration/gitaly/index.md

@@ -101,8 +101,7 @@ documentation on configuring Gitaly
 authentication](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configuration/README.md#authentication)
 .
 
-> 
-**NOTE:** In most or all cases the storage paths below end in `/repositories` which is 
+> **NOTE:** In most or all cases the storage paths below end in `/repositories` which is 
 different than `path` in `git_data_dirs` of Omnibus installations. Check the
 directory layout on your Gitaly server to be sure.
 

doc/administration/high_availability/gitlab.md

@@ -84,7 +84,7 @@ for each GitLab application server in your environment.
     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
     above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
     certificates are not present, Nginx will fail to start. See

doc/administration/high_availability/redis.md

 # Configuring Redis for GitLab HA
 
->
-Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11.
+> Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11.
 Starting with 8.14, Redis Sentinel is no longer experimental.
 If you've used it with versions `< 8.14` before, please check the updated
 documentation here.
@@ -15,20 +14,20 @@ a hosted cloud solution or you can use the one that comes bundled with
 Omnibus GitLab packages.
 
 > **Notes:**
-- Redis requires authentication for High Availability. See
-  [Redis Security](http://redis.io/topics/security) documentation for more
-  information. We recommend using a combination of a Redis password and tight
-  firewall rules to secure your Redis service.
-- You are highly encouraged to read the [Redis Sentinel][sentinel] documentation
-  before configuring Redis HA with GitLab to fully understand the topology and
-  architecture.
-- This is the documentation for the Omnibus GitLab packages. For installations
-  from source, follow the [Redis HA source installation](redis_source.md) guide.
-- Redis Sentinel daemon is bundled with Omnibus GitLab Enterprise Edition only.
-  For configuring Sentinel with the Omnibus GitLab Community Edition and
-  installations from source, read the
-  [Available configuration setups](#available-configuration-setups) section
-  below.
+> - Redis requires authentication for High Availability. See
+>  [Redis Security](http://redis.io/topics/security) documentation for more
+>  information. We recommend using a combination of a Redis password and tight
+>  firewall rules to secure your Redis service.
+> - You are highly encouraged to read the [Redis Sentinel][sentinel] documentation
+>  before configuring Redis HA with GitLab to fully understand the topology and
+>  architecture.
+> - This is the documentation for the Omnibus GitLab packages. For installations
+>  from source, follow the [Redis HA source installation](redis_source.md) guide.
+> - Redis Sentinel daemon is bundled with Omnibus GitLab Enterprise Edition only.
+>  For configuring Sentinel with the Omnibus GitLab Community Edition and
+>  installations from source, read the
+>  [Available configuration setups](#available-configuration-setups) section
+>  below.
 
 ## Overview
 
@@ -55,11 +54,11 @@ components below.
 
 ### High Availability with Sentinel
 
->**Notes:**
-- Starting with GitLab `8.11`, you can configure a list of Redis Sentinel
-  servers that will monitor a group of Redis servers to provide failover support.
-- Starting with GitLab `8.14`, the Omnibus GitLab Enterprise Edition package
-  comes with Redis Sentinel daemon built-in.
+> **Notes:**
+> - Starting with GitLab `8.11`, you can configure a list of Redis Sentinel
+>   servers that will monitor a group of Redis servers to provide failover support.
+> - Starting with GitLab `8.14`, the Omnibus GitLab Enterprise Edition package
+>  comes with Redis Sentinel daemon built-in.
 
 High Availability with Redis requires a few things:
 
@@ -231,13 +230,13 @@ Pick the one that suits your needs.
 
 This is the section where we install and setup the new Redis instances.
 
->**Notes:**
-- We assume that you have installed GitLab and all HA components from scratch. If you
-  already have it installed and running, read how to
-  [switch from a single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha).
-- Redis nodes (both master and slaves) will need the same password defined in
-  `redis['password']`. At any time during a failover the Sentinels can
-  reconfigure a node and change its status from master to slave and vice versa.
+> **Notes:**
+> - We assume that you have installed GitLab and all HA components from scratch. If you
+>   already have it installed and running, read how to
+>   [switch from a single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha).
+> - Redis nodes (both master and slaves) will need the same password defined in
+>   `redis['password']`. At any time during a failover the Sentinels can
+>  reconfigure a node and change its status from master to slave and vice versa.
 
 ### Prerequisites
 

doc/administration/integration/koding.md

 # Koding & GitLab
 
->**Notes:**
-- **As of GitLab 10.0, the Koding integration is deprecated and will be removed
-  in a future version. The option to configure it is removed from GitLab's admin
-  area.**
-- [Introduced][ce-5909] in GitLab 8.11.
+> **Notes:**
+> - **As of GitLab 10.0, the Koding integration is deprecated and will be removed
+>   in a future version. The option to configure it is removed from GitLab's admin
+>   area.**
+> - [Introduced][ce-5909] in GitLab 8.11.
 
 This document will guide you through installing and configuring Koding with
 GitLab.
@@ -117,12 +117,11 @@ requests.
 You need to enable Koding integration from Settings under Admin Area. To do
 that login with an Admin account and do followings;
 
- - open [http://127.0.0.1:3000/admin/application_settings](http://127.0.0.1:3000/admin/application_settings)
- - scroll to bottom of the page until Koding section
- - check `Enable Koding` checkbox
- - provide GitLab team page for running Koding instance as `Koding URL`*
-
-* For `Koding URL` you need to provide the gitlab integration enabled team on
+- open [http://127.0.0.1:3000/admin/application_settings](http://127.0.0.1:3000/admin/application_settings)
+- scroll to bottom of the page until Koding section
+- check `Enable Koding` checkbox
+- provide GitLab team page for running Koding instance as `Koding URL`*
+  * For `Koding URL` you need to provide the gitlab integration enabled team on
 your Koding installation. Team called `gitlab` has integration on Koding out
 of the box, so if you didn't change anything your team on Koding should be
 `gitlab`.

doc/administration/integration/plantuml.md

@@ -74,28 +74,27 @@ our AsciiDoc snippets, wikis and repos using delimited blocks:
     ```plantuml
     Bob -> Alice : hello
     Alice -> Bob : Go Away
-    ```
-    </pre>
+    ```</pre>
 
 - **AsciiDoc**
 
-    <pre>
+    ```
     [plantuml, format="png", id="myDiagram", width="200px"]
     --
     Bob->Alice : hello
     Alice -> Bob : Go Away
     --
-    </pre>
+    ```
 
 - **reStructuredText**
 
-    <pre>
+    ```
     .. plantuml::
        :caption: Caption with **bold** and *italic*
 
        Bob -> Alice: hello
        Alice -> Bob: Go Away
-    </pre>
+    ```
 
     You can also use the `uml::` directive for compatibility with [sphinxcontrib-plantuml](https://pypi.python.org/pypi/sphinxcontrib-plantuml), but please note that we currently only support the `caption` option.
 

doc/administration/integration/terminal.md

 # Web terminals
 
->
-[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
 in GitLab 8.15. Only project maintainers and owners can access web terminals.
 
 With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),

doc/administration/job_artifacts.md

@@ -87,13 +87,13 @@ _The artifacts are stored by default in
 
 ### Using object storage
 
->**Notes:**
-- [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1762) in
-  [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
-- Since version 9.5, artifacts are [browsable](../user/project/pipelines/job_artifacts.md#browsing-artifacts),
-  when object storage is enabled. 9.4 lacks this feature.
-- Since version 10.6, available in [GitLab Core](https://about.gitlab.com/pricing/)
-- Since version 11.0, we support `direct_upload` to S3.
+> **Notes:**
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1762) in
+>   [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
+> - Since version 9.5, artifacts are [browsable](../user/project/pipelines/job_artifacts.md#browsing-artifacts),
+>   when object storage is enabled. 9.4 lacks this feature.
+> - Since version 10.6, available in [GitLab Core](https://about.gitlab.com/pricing/)
+> - Since version 11.0, we support `direct_upload` to S3.
 
 If you don't want to use the local disk where GitLab is installed to store the
 artifacts, you can use an object storage like AWS S3 instead.
@@ -266,6 +266,7 @@ you can flip the feature flag from a Rails console.
     ```ruby
     Feature.enable('ci_disable_validates_dependencies')
     ```
+
 ---
 
 **In installations from source:**

doc/administration/monitoring/prometheus/index.md

 # GitLab Prometheus
 
->**Notes:**
-- Prometheus and the various exporters listed in this page are bundled in the
-  Omnibus GitLab package. Check each exporter's documentation for the timeline
-  they got added. For installations from source you will have to install them
-  yourself. Over subsequent releases additional GitLab metrics will be captured.
-- Prometheus services are on by default with GitLab 9.0.
-- Prometheus and its exporters do not authenticate users, and will be available
-  to anyone who can access them.
+> **Notes:**
+> - Prometheus and the various exporters listed in this page are bundled in the
+>   Omnibus GitLab package. Check each exporter's documentation for the timeline
+>   they got added. For installations from source you will have to install them
+>   yourself. Over subsequent releases additional GitLab metrics will be captured.
+> - Prometheus services are on by default with GitLab 9.0.
+> - Prometheus and its exporters do not authenticate users, and will be available
+>  to anyone who can access them.
 
 [Prometheus] is a powerful time-series monitoring service, providing a flexible
 platform for monitoring GitLab and other software products.
@@ -107,7 +107,7 @@ Sample Prometheus queries:
 > Introduced in GitLab 9.0.
 > Pod monitoring introduced in GitLab 9.4.
 
-If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/operating/configuration/#<kubernetes_sd_config>) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][] to monitor them.
+If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/operating/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][] to monitor them.
 
 To disable the monitoring of Kubernetes:
 

doc/administration/pages/index.md

@@ -5,13 +5,13 @@ description: 'Learn how to administer GitLab Pages.'
 # GitLab Pages administration
 
 > **Notes:**
-- [Introduced][ee-80] in GitLab EE 8.3.
-- Custom CNAMEs with TLS support were [introduced][ee-173] in GitLab EE 8.5.
-- GitLab Pages [were ported][ce-14605] to Community Edition in GitLab 8.17.
-- This guide is for Omnibus GitLab installations. If you have installed
-  GitLab from source, follow the [Pages source installation document](source.md).
-- To learn how to use GitLab Pages, read the [user documentation][pages-userguide].
-- Does NOT support subgroups. See [this issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) for more information and status.
+> - [Introduced][ee-80] in GitLab EE 8.3.
+> - Custom CNAMEs with TLS support were [introduced][ee-173] in GitLab EE 8.5.
+> - GitLab Pages [were ported][ce-14605] to Community Edition in GitLab 8.17.
+> - This guide is for Omnibus GitLab installations. If you have installed
+>   GitLab from source, follow the [Pages source installation document](source.md).
+> - To learn how to use GitLab Pages, read the [user documentation][pages-userguide].
+> - Does NOT support subgroups. See [this issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) for more information and status.
 
 This document describes how to set up the _latest_ GitLab Pages feature. Make
 sure to read the [changelog](#changelog) if you are upgrading to a new GitLab
@@ -107,12 +107,12 @@ since that is needed in all configurations.
 
 ### Wildcard domains
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
 >
->---
+> ---
 >
-URL scheme: `http://page.example.io`
+> URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
 other setups as described below. Nginx will proxy all requests to the daemon.
@@ -131,13 +131,13 @@ Watch the [video tutorial][video-admin] for this configuration.
 
 ### Wildcard domains with TLS support
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
-- Wildcard TLS certificate
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
+> - Wildcard TLS certificate
 >
->---
+> ---
 >
-URL scheme: `https://page.example.io`
+> URL scheme: `https://page.example.io`
 
 Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
@@ -168,13 +168,13 @@ you have IPv6 as well as IPv4 addresses, you can use them both.
 
 ### Custom domains
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
-- Secondary IP
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
+> - Secondary IP
 >
----
+> ---
 >
-URL scheme: `http://page.example.io` and `http://domain.com`
+> URL scheme: `http://page.example.io` and `http://domain.com`
 
 In that case, the Pages daemon is running, Nginx still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
@@ -197,14 +197,14 @@ world. Custom domains are supported, but no TLS.
 
 ### Custom domains with TLS support
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
-- Wildcard TLS certificate
-- Secondary IP
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
+> - Wildcard TLS certificate
+> - Secondary IP
 >
----
+> ---
 >
-URL scheme: `https://page.example.io` and `https://domain.com`
+> URL scheme: `https://page.example.io` and `https://domain.com`
 
 In that case, the Pages daemon is running, Nginx still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside

doc/administration/pages/source.md

@@ -89,11 +89,11 @@ since that is needed in all configurations.
 ### Wildcard domains
 
 >**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
+> - [Wildcard DNS setup](#dns-configuration)
 >
->---
+> ---
 >
-URL scheme: `http://page.example.io`
+> URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
 other setups as described below. Nginx will proxy all requests to the daemon.
@@ -151,13 +151,13 @@ The Pages daemon doesn't listen to the outside world.
 
 ### Wildcard domains with TLS support
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
-- Wildcard TLS certificate
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
+> - Wildcard TLS certificate
 >
->---
+> ---
 >
-URL scheme: `https://page.example.io`
+> URL scheme: `https://page.example.io`
 
 Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
@@ -216,13 +216,13 @@ that without TLS certificates.
 
 ### Custom domains
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
-- Secondary IP
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
+> - Secondary IP
 >
----
+> ---
 >
-URL scheme: `http://page.example.io` and `http://domain.com`
+> URL scheme: `http://page.example.io` and `http://domain.com`
 
 In that case, the pages daemon is running, Nginx still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
@@ -281,14 +281,14 @@ world. Custom domains are supported, but no TLS.
 
 ### Custom domains with TLS support
 
->**Requirements:**
-- [Wildcard DNS setup](#dns-configuration)
-- Wildcard TLS certificate
-- Secondary IP
+> **Requirements:**
+> - [Wildcard DNS setup](#dns-configuration)
+> - Wildcard TLS certificate
+> - Secondary IP
 >
----
+> ---
 >
-URL scheme: `https://page.example.io` and `https://domain.com`
+> URL scheme: `https://page.example.io` and `https://domain.com`
 
 In that case, the pages daemon is running, Nginx still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside

doc/administration/repository_storage_paths.md

@@ -5,36 +5,36 @@
 GitLab allows you to define multiple repository storage paths to distribute the
 storage load between several mount points.
 
->**Notes:**
+> **Notes:**
 >
-- You must have at least one storage path called `default`.
-- The paths are defined in key-value pairs. The key is an arbitrary name you
-  can pick to name the file path.
-- The target directories and any of its subpaths must not be a symlink.
+> - You must have at least one storage path called `default`.
+> - The paths are defined in key-value pairs. The key is an arbitrary name you
+>   can pick to name the file path.
+> - The target directories and any of its subpaths must not be a symlink.
 
 ## Configure GitLab
 
->**Warning:**
-In order for [backups] to work correctly, the storage path must **not** be a
-mount point and the GitLab user should have correct permissions for the parent
-directory of the path. In Omnibus GitLab this is taken care of automatically,
-but for source installations you should be extra careful.
+> **Warning:**
+> In order for [backups] to work correctly, the storage path must **not** be a
+> mount point and the GitLab user should have correct permissions for the parent
+> directory of the path. In Omnibus GitLab this is taken care of automatically,
+> but for source installations you should be extra careful.
 >
-The thing is that for compatibility reasons `gitlab.yml` has a different
-structure than Omnibus. In `gitlab.yml` you indicate the path for the
-repositories, for example `/home/git/repositories`, while in Omnibus you
-indicate `git_data_dirs`, which for the example above would be `/home/git`.
-Then, Omnibus will create a `repositories` directory under that path to use with
-`gitlab.yml`.
+> The thing is that for compatibility reasons `gitlab.yml` has a different
+> structure than Omnibus. In `gitlab.yml` you indicate the path for the
+> repositories, for example `/home/git/repositories`, while in Omnibus you
+> indicate `git_data_dirs`, which for the example above would be `/home/git`.
+> Then, Omnibus will create a `repositories` directory under that path to use with
+> `gitlab.yml`.
 >
-This little detail matters because while restoring a backup, the current
-contents of  `/home/git/repositories` [are moved to][raketask] `/home/git/repositories.old`,
-so if `/home/git/repositories` is the mount point, then `mv` would be moving
-things between mount points, and bad things could happen. Ideally,
-`/home/git` would be the mount point, so then things would be moving within the
-same mount point. This is guaranteed with Omnibus installations (because they
-don't specify the full repository path but the parent path), but not for source
-installations.
+> This little detail matters because while restoring a backup, the current
+> contents of  `/home/git/repositories` [are moved to][raketask] `/home/git/repositories.old`,
+> so if `/home/git/repositories` is the mount point, then `mv` would be moving
+> things between mount points, and bad things could happen. Ideally,
+> `/home/git` would be the mount point, so then things would be moving within the
+> same mount point. This is guaranteed with Omnibus installations (because they
+> don't specify the full repository path but the parent path), but not for source
+> installations.
 
 ---
 

doc/administration/troubleshooting/sidekiq.md

@@ -8,15 +8,15 @@ may not show up and merge requests may not be updated. The following are some
 troubleshooting steps that will help you diagnose the bottleneck.
 
 > **Note:** GitLab administrators/users should consider working through these
-debug steps with GitLab Support so the backtraces can be analyzed by our team.
-It may reveal a bug or necessary improvement in GitLab.
-
+> debug steps with GitLab Support so the backtraces can be analyzed by our team.
+> It may reveal a bug or necessary improvement in GitLab.
+>
 > **Note:** In any of the backtraces, be wary of suspecting cases where every
-  thread appears to be waiting in the database, Redis, or waiting to acquire
-  a mutex. This **may** mean there's contention in the database, for example,
-  but look for one thread that is different than the rest. This other thread
-  may be using all available CPU, or have a Ruby Global Interpreter Lock,
-  preventing other threads from continuing.
+> thread appears to be waiting in the database, Redis, or waiting to acquire
+> a mutex. This **may** mean there's contention in the database, for example,
+> but look for one thread that is different than the rest. This other thread
+> may be using all available CPU, or have a Ruby Global Interpreter Lock,
+> preventing other threads from continuing.
 
 ## Thread dump
 

doc/administration/uploads.md

@@ -50,9 +50,10 @@ _The uploads are stored by default in
 
 ### Using object storage
 
->**Notes:**
-- [Introduced][ee-3867] in [GitLab Enterprise Edition Premium][eep] 10.5.
-- Since version 11.1, we support direct_upload to S3.
+> **Notes:**
+>
+> - [Introduced][ee-3867] in [GitLab Enterprise Edition Premium][eep] 10.5.
+> - Since version 11.1, we support direct_upload to S3.
 
 If you don't want to use the local disk where GitLab is installed to store the
 uploads, you can use an object storage provider like AWS S3 instead.
@@ -105,8 +106,8 @@ _The uploads are stored by default in
     }
     ```
 
->**Note:**
-If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
+	>**Note:**
+	If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
 
     ```ruby
     gitlab_rails['uploads_object_store_connection'] = {
@@ -119,8 +120,8 @@ If you are using AWS IAM profiles, be sure to omit the AWS access key and secret
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local uploads to the object storage:
 
->**Notes:**
-These task complies with the `BATCH` environment variable to process uploads in batch (200 by default). All of the processing will be done in a background worker and requires **no downtime**.
+    > **Notes:**
+    > These task complies with the `BATCH` environment variable to process uploads in batch (200 by default). All of the processing will be done in a background worker and requires **no downtime**.
 
     ```bash
     # gitlab-rake gitlab:uploads:migrate[uploader_class, model_class, mount_point]
@@ -167,11 +168,9 @@ _The uploads are stored by default in
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local uploads to the object storage:
 
->**Notes:**
-
-- These task comply with the `BATCH` environment variable to process uploads in batch (200 by default). All of the processing will be done in a background worker and requires **no downtime**.
-
-- To migrate in production use `RAILS_ENV=production` environment variable.
+    > **Notes:**
+    > - These task comply with the `BATCH` environment variable to process uploads in batch (200 by default). All of the processing will be done in a background worker and requires **no downtime**.
+    > - To migrate in production use `RAILS_ENV=production` environment variable.
 
     ```bash
     # sudo -u git -H bundle exec rake gitlab:uploads:migrate

doc/api/jobs.md

@@ -319,7 +319,8 @@ Example of response
 ## Get job artifacts
 
 > **Notes**:
-- [Introduced][ce-2893] in GitLab 8.5.
+> 
+> - [Introduced][ce-2893] in GitLab 8.5.
 
 Get job artifacts of a project.
 
@@ -350,7 +351,8 @@ Response:
 ## Download the artifacts archive
 
 > **Notes**:
-- [Introduced][ce-5347] in GitLab 8.10.
+> 
+> - [Introduced][ce-5347] in GitLab 8.10.
 
 Download the artifacts archive from the given reference name and job provided the
 job finished successfully.

doc/api/services.md

@@ -544,10 +544,10 @@ GET /projects/:id/services/jira
 
 Set JIRA service for a project.
 
->**Notes:**
-- Starting with GitLab 8.14, `api_url`, `issues_url`, `new_issue_url` and
-  `project_url` are replaced by `project_key`, `url`.  If you are using an
-  older version, [follow this documentation][old-jira-api].
+> **Notes:**
+> - Starting with GitLab 8.14, `api_url`, `issues_url`, `new_issue_url` and
+>   `project_url` are replaced by `project_key`, `url`.  If you are using an
+>   older version, [follow this documentation][old-jira-api].
 
 ```
 PUT /projects/:id/services/jira

doc/api/v3_to_v4.md

@@ -76,8 +76,8 @@ Below are the changes made between V3 and V4.
 - Simplify project payload exposed on Environment endpoints [!9675](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9675)
 - API uses merge request `IID`s (internal ID, as in the web UI) rather than `ID`s. This affects the merge requests, award emoji, todos, and time tracking APIs. [!9530](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9530)
 - API uses issue `IID`s (internal ID, as in the web UI) rather than `ID`s. This affects the issues, award emoji, todos, and time tracking APIs. [!9530](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9530)
-- Change initial page from `0` to `1` on `GET /projects/:id/repository/commits` (like on the rest of the API) [!9679] (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9679)
-- Return correct `Link` header data for `GET /projects/:id/repository/commits` [!9679] (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9679)
+- Change initial page from `0` to `1` on `GET /projects/:id/repository/commits` (like on the rest of the API) [!9679](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9679)
+- Return correct `Link` header data for `GET /projects/:id/repository/commits` [!9679](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9679)
 - Update endpoints for repository files [!9637](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9637)
   - Moved `GET /projects/:id/repository/files?file_path=:file_path` to `GET /projects/:id/repository/files/:file_path` (`:file_path` should be URL-encoded)
   - `GET /projects/:id/repository/blobs/:sha` now returns JSON attributes for the blob identified by `:sha`, instead of finding the commit identified by `:sha` and returning the raw content of the blob in that commit identified by the required `?filepath=:filepath`

doc/ci/docker/using_docker_build.md

@@ -381,17 +381,18 @@ environment = ["DOCKER_DRIVER=overlay2"]
 If you're running multiple Runners you will have to modify all configuration files.
 
 > **Notes:**
-- More information about the Runner configuration is available in the [Runner documentation](https://docs.gitlab.com/runner/configuration/).
-- For more information about using OverlayFS with Docker, you can read
-  [Use the OverlayFS storage driver](https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/).
+>
+> - More information about the Runner configuration is available in the [Runner documentation](https://docs.gitlab.com/runner/configuration/).
+> - For more information about using OverlayFS with Docker, you can read
+>   [Use the OverlayFS storage driver](https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/).
 
 ## Using the GitLab Container Registry
 
 > **Notes:**
-- This feature requires GitLab 8.8 and GitLab Runner 1.2.
-- Starting from GitLab 8.12, if you have [2FA] enabled in your account, you need
-  to pass a [personal access token][pat] instead of your password in order to
-  login to GitLab's Container Registry.
+> - This feature requires GitLab 8.8 and GitLab Runner 1.2.
+> - Starting from GitLab 8.12, if you have [2FA] enabled in your account, you need
+>   to pass a [personal access token][pat] instead of your password in order to
+>   login to GitLab's Container Registry.
 
 Once you've built a Docker image, you can push it up to the built-in
 [GitLab Container Registry](../../user/project/container_registry.md). For example,

doc/ci/docker/using_docker_images.md

@@ -452,13 +452,14 @@ that runner.
 ## Define an image from a private Container Registry
 
 > **Notes:**
-- This feature requires GitLab Runner **1.8** or higher
-- For GitLab Runner versions **>= 0.6, <1.8** there was a partial
-  support for using private registries, which required manual configuration
-  of credentials on runner's host. We recommend to upgrade your Runner to
-  at least version **1.8** if you want to use private registries.
-- If the repository is private you need to authenticate your GitLab Runner in the
-  registry. Learn more about how [GitLab Runner works in this case][runner-priv-reg].
+>
+> - This feature requires GitLab Runner **1.8** or higher
+> - For GitLab Runner versions **>= 0.6, <1.8** there was a partial
+>   support for using private registries, which required manual configuration
+>   of credentials on runner's host. We recommend to upgrade your Runner to
+>   at least version **1.8** if you want to use private registries.
+> - If the repository is private you need to authenticate your GitLab Runner in the
+>   registry. Learn more about how [GitLab Runner works in this case][runner-priv-reg].
 
 As an example, let's assume that you want to use the `registry.example.com/private/image:latest`
 image which is private and requires you to login into a private container registry.

doc/ci/environments.md

@@ -87,18 +87,18 @@ will later see, is exposed in various places within GitLab. Each time a job that
 has an environment specified and succeeds, a deployment is recorded, remembering
 the Git SHA and environment name.
 
->**Note:**
-Starting with GitLab 8.15, the environment name is exposed to the Runner in
-two forms: `$CI_ENVIRONMENT_NAME`, and `$CI_ENVIRONMENT_SLUG`. The first is
-the name given in `.gitlab-ci.yml` (with any variables expanded), while the
-second is a "cleaned-up" version of the name, suitable for use in URLs, DNS,
-etc.
-
->**Note:**
-Starting with GitLab 9.3, the environment URL is exposed to the Runner via
-`$CI_ENVIRONMENT_URL`. The URL would be expanded from `.gitlab-ci.yml`, or if
-the URL was not defined there, the external URL from the environment would be
-used.
+> **Note:**
+> Starting with GitLab 8.15, the environment name is exposed to the Runner in
+> two forms: `$CI_ENVIRONMENT_NAME`, and `$CI_ENVIRONMENT_SLUG`. The first is
+> the name given in `.gitlab-ci.yml` (with any variables expanded), while the
+> second is a "cleaned-up" version of the name, suitable for use in URLs, DNS,
+> etc.
+>
+> **Note:**
+> Starting with GitLab 9.3, the environment URL is exposed to the Runner via
+> `$CI_ENVIRONMENT_URL`. The URL would be expanded from `.gitlab-ci.yml`, or if
+> the URL was not defined there, the external URL from the environment would be
+> used.
 
 To sum up, with the above `.gitlab-ci.yml` we have achieved that:
 
@@ -134,14 +134,15 @@ There's a bunch of information there, specifically you can see:
 - A button that re-deploys the latest deployment, meaning it runs the job
   defined by the environment name for that specific commit
 
->**Notes:**
-- While you can create environments manually in the web interface, we recommend
-  that you define your environments in `.gitlab-ci.yml` first. They will
-  be automatically created for you after the first deploy.
-- The environments page can only be viewed by Reporters and above. For more
-  information on the permissions, see the [permissions documentation][permissions].
-- Only deploys that happen after your `.gitlab-ci.yml` is properly configured
-  will show up in the "Environment" and "Last deployment" lists.
+> **Notes:**
+>
+> - While you can create environments manually in the web interface, we recommend
+>   that you define your environments in `.gitlab-ci.yml` first. They will
+>   be automatically created for you after the first deploy.
+> - The environments page can only be viewed by Reporters and above. For more
+>   information on the permissions, see the [permissions documentation][permissions].
+> - Only deploys that happen after your `.gitlab-ci.yml` is properly configured
+>   will show up in the "Environment" and "Last deployment" lists.
 
 The information shown in the Environments page is limited to the latest
 deployments, but as you may have guessed an environment can have multiple
@@ -563,13 +564,13 @@ exist, you should see something like:
 
 ## Monitoring environments
 
->**Notes:**
+> **Notes:**
 >
-- For the monitoring dashboard to appear, you need to:
-  - Have enabled the [Prometheus integration][prom]
-  - Configured Prometheus to collect at least one [supported metric](../user/project/integrations/prometheus_library/metrics.md)
-- With GitLab 9.2, all deployments to an environment are shown directly on the
-  monitoring dashboard
+> - For the monitoring dashboard to appear, you need to:
+>   - Have enabled the [Prometheus integration][prom]
+>   - Configured Prometheus to collect at least one [supported metric](../user/project/integrations/prometheus_library/metrics.md)
+> - With GitLab 9.2, all deployments to an environment are shown directly on the
+>  monitoring dashboard
 
 If you have enabled [Prometheus for monitoring system and response metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html), you can monitor the performance behavior of your app running in each environment.
 

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -85,7 +85,7 @@ When asked, answer `Y` to fetch and install dependencies.
 
 If everything went fine, you'll get an output like this:
 
-![`mix phoenix.new`](img/mix-phoenix-new.png)
+![mix phoenix.new](img/mix-phoenix-new.png)
 
 Now, our project is located inside the directory with the same name we pass to `mix` command, for
 example, `~/GitLab/hello_gitlab_ci`.
@@ -145,7 +145,7 @@ Now, we have our app running locally. We can preview it directly on our browser.
 not work, open [`127.0.0.1:4000`](http://127.0.0.1:4000) instead and later, configure your OS to
 point `localhost` to `127.0.0.1`.
 
-![`mix phoenix.server`](img/mix-phoenix-server.png)
+![mix phoenix.server](img/mix-phoenix-server.png)
 
 Great, now we have a local Phoenix Server running our app.
 

doc/ci/git_submodules.md

 # Using Git submodules with GitLab CI
 
 > **Notes:**
-- GitLab 8.12 introduced a new [CI job permissions model][newperms] and you
-  are encouraged to upgrade your GitLab instance if you haven't done already.
-  If you are **not** using GitLab 8.12 or higher, you would need to work your way
-  around submodules in order to access the sources of e.g., `gitlab.com/group/project`
-  with the use of [SSH keys](ssh_keys/README.md).
-- With GitLab 8.12 onward, your permissions are used to evaluate what a CI job
-  can access. More information about how this system works can be found in the
-  [Jobs permissions model](../user/permissions.md#job-permissions).
-- The HTTP(S) Git protocol [must be enabled][gitpro] in your GitLab instance.
+>
+> - GitLab 8.12 introduced a new [CI job permissions model][newperms] and you
+>   are encouraged to upgrade your GitLab instance if you haven't done already.
+>   If you are **not** using GitLab 8.12 or higher, you would need to work your way
+>   around submodules in order to access the sources of e.g., `gitlab.com/group/project`
+>   with the use of [SSH keys](ssh_keys/README.md).
+> - With GitLab 8.12 onward, your permissions are used to evaluate what a CI job
+>   can access. More information about how this system works can be found in the
+>   [Jobs permissions model](../user/permissions.md#job-permissions).
+> - The HTTP(S) Git protocol [must be enabled][gitpro] in your GitLab instance.
 
 ## Configuring the `.gitmodules` file
 

doc/ci/review_apps/index.md

 # Getting started with Review Apps
 
->
-- [Introduced][ce-21971] in GitLab 8.12. Further additions were made in GitLab
-  8.13 and 8.14.
-- Inspired by [Heroku's Review Apps][heroku-apps] which itself was inspired by
-  [Fourchette].
+> - [Introduced][ce-21971] in GitLab 8.12. Further additions were made in GitLab
+>   8.13 and 8.14.
+> - Inspired by [Heroku's Review Apps][heroku-apps] which itself was inspired by
+>  [Fourchette].
 
 The basis of Review Apps is the [dynamic environments] which allow you to create
 a new environment (dynamically) for each one of your branches.

doc/ci/runners/README.md

@@ -144,9 +144,8 @@ An admin can enable/disable a specific Runner for projects:
 
 ## Protected Runners
 
->
-[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13194)
-in GitLab 10.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13194)
+> in GitLab 10.0.
 
 You can protect Runners from revealing sensitive information.
 Whenever a Runner is protected, the Runner picks only jobs created on

doc/ci/ssh_keys/README.md

@@ -46,7 +46,7 @@ to access it. This is where an SSH key pair comes in handy.
 
 1. You will first need to create an SSH key pair. For more information, follow
    the instructions to [generate an SSH key](../../ssh/README.md#generating-a-new-ssh-key-pair).
-   **Do not** add a passphrase to the SSH key, or the `before_script` will\
+   **Do not** add a passphrase to the SSH key, or the `before_script` will
    prompt for it.
 
 1. Create a new [variable](../variables/README.md#variables).
@@ -175,7 +175,7 @@ Now that the `SSH_KNOWN_HOSTS` variable is created, in addition to the
 [content of `.gitlab-ci.yml`](#ssh-keys-when-using-the-docker-executor)
 above, here's what more you need to add:
 
- ```yaml
+```yaml
 before_script:
   ##
   ## Assuming you created the SSH_KNOWN_HOSTS variable, uncomment the

doc/ci/triggers/README.md

 # Triggering pipelines through the API
 
 > **Notes**:
-- [Introduced][ci-229] in GitLab CE 7.14.
-- GitLab 8.12 has a completely redesigned job permissions system. Read all
-  about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers).
+>
+> - [Introduced][ci-229] in GitLab CE 7.14.
+> - GitLab 8.12 has a completely redesigned job permissions system. Read all
+>   about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers).
 
 Triggers can be used to force a pipeline rerun of a specific `ref` (branch or
 tag) with an API call.
@@ -49,11 +50,12 @@ The action is irreversible.
 ## Triggering a pipeline
 
 > **Notes**:
-- Valid refs are only the branches and tags. If you pass a commit SHA as a ref,
-  it will not trigger a job.
-- If your project is public, passing the token in plain text is probably not the
-  wisest idea, so you might want to use a
-  [variable](../variables/README.md#variables) for that purpose.
+>
+> - Valid refs are only the branches and tags. If you pass a commit SHA as a ref,
+>   it will not trigger a job.
+> - If your project is public, passing the token in plain text is probably not the
+>   wisest idea, so you might want to use a
+>   [variable](../variables/README.md#variables) for that purpose.
 
 To trigger a job you need to send a `POST` request to GitLab's API endpoint:
 
@@ -122,11 +124,12 @@ Now, whenever a new tag is pushed on project A, the job will run and the
 ## Triggering a pipeline from a webhook
 
 > **Notes**:
-- Introduced in GitLab 8.14.
-- `ref` should be passed as part of the URL in order to take precedence over
-  `ref` from the webhook body that designates the branch ref that fired the
-  trigger in the source repository.
-- `ref` should be URL-encoded if it contains slashes.
+>
+> - Introduced in GitLab 8.14.
+> - `ref` should be passed as part of the URL in order to take precedence over
+>   `ref` from the webhook body that designates the branch ref that fired the
+>   trigger in the source repository.
+> - `ref` should be URL-encoded if it contains slashes.
 
 To trigger a job from a webhook of another project you need to add the following
 webhook URL for Push and Tag events (change the project ID, ref and token):

doc/ci/yaml/README.md

@@ -383,7 +383,7 @@ except master.
 ## `only` and `except` (complex)
 
 > `refs` and `kubernetes` policies introduced in GitLab 10.0
-
+>
 > `variables` policy introduced in 10.7
 
 CAUTION: **Warning:**
@@ -583,9 +583,10 @@ The above script will:
 ### `when:manual`
 
 > **Notes:**
-- Introduced in GitLab 8.10.
-- Blocking manual actions were introduced in GitLab 9.0.
-- Protected actions were introduced in GitLab 9.2.
+>
+> - Introduced in GitLab 8.10.
+> - Blocking manual actions were introduced in GitLab 9.0.
+> - Protected actions were introduced in GitLab 9.2.
 
 Manual actions are a special type of job that are not executed automatically,
 they need to be explicitly started by a user. An example usage of manual actions
@@ -616,11 +617,11 @@ have ability to merge to this branch.
 
 ## `environment`
 
+> **Notes:**
 >
-**Notes:**
-- Introduced in GitLab 8.9.
-- You can read more about environments and find more examples in the
-  [documentation about environments][environment].
+> - Introduced in GitLab 8.9.
+> - You can read more about environments and find more examples in the
+>   [documentation about environments][environment].
 
 `environment` is used to define that a job deploys to a specific environment.
 If `environment` is specified and no environment under that name exists, a new
@@ -641,15 +642,15 @@ deployment to the `production` environment.
 
 ### `environment:name`
 
+> **Notes:**
 >
-**Notes:**
-- Introduced in GitLab 8.11.
-- Before GitLab 8.11, the name of an environment could be defined as a string like
-  `environment: production`. The recommended way now is to define it under the
-  `name` keyword.
-- The `name` parameter can use any of the defined CI variables,
-  including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
-  You however cannot use variables defined under `script`.
+> - Introduced in GitLab 8.11.
+> - Before GitLab 8.11, the name of an environment could be defined as a string like
+>   `environment: production`. The recommended way now is to define it under the
+>   `name` keyword.
+> - The `name` parameter can use any of the defined CI variables,
+>   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
+>   You however cannot use variables defined under `script`.
 
 The `environment` name can contain:
 
@@ -680,14 +681,14 @@ deploy to production:
 
 ### `environment:url`
 
+> **Notes:**
 >
-**Notes:**
-- Introduced in GitLab 8.11.
-- Before GitLab 8.11, the URL could be added only in GitLab's UI. The
-  recommended way now is to define it in `.gitlab-ci.yml`.
-- The `url` parameter can use any of the defined CI variables,
-  including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
-  You however cannot use variables defined under `script`.
+> - Introduced in GitLab 8.11.
+> - Before GitLab 8.11, the URL could be added only in GitLab's UI. The
+>   recommended way now is to define it in `.gitlab-ci.yml`.
+> - The `url` parameter can use any of the defined CI variables,
+>   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
+>   You however cannot use variables defined under `script`.
 
 This is an optional value that when set, it exposes buttons in various places
 in GitLab which when clicked take you to the defined URL.
@@ -707,12 +708,12 @@ deploy to production:
 
 ### `environment:on_stop`
 
+> **Notes:**
 >
-**Notes:**
-- [Introduced][ce-6669] in GitLab 8.13.
-- Starting with GitLab 8.14, when you have an environment that has a stop action
-  defined, GitLab will automatically trigger a stop action when the associated
-  branch is deleted.
+> - [Introduced][ce-6669] in GitLab 8.13.
+> - Starting with GitLab 8.14, when you have an environment that has a stop action
+>   defined, GitLab will automatically trigger a stop action when the associated
+>   branch is deleted.
 
 Closing (stoping) environments can be achieved with the `on_stop` keyword defined under
 `environment`. It declares a different job that runs in order to close
@@ -763,13 +764,13 @@ The `stop_review_app` job is **required** to have the following keywords defined
 
 ### Dynamic environments
 
+> **Notes:**
 >
-**Notes:**
-- [Introduced][ce-6323] in GitLab 8.12 and GitLab Runner 1.6.
-- The `$CI_ENVIRONMENT_SLUG` was [introduced][ce-7983] in GitLab 8.15.
-- The `name` and `url` parameters can use any of the defined CI variables,
-  including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
-  You however cannot use variables defined under `script`.
+> - [Introduced][ce-6323] in GitLab 8.12 and GitLab Runner 1.6.
+> - The `$CI_ENVIRONMENT_SLUG` was [introduced][ce-7983] in GitLab 8.15.
+> - The `name` and `url` parameters can use any of the defined CI variables,
+>   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
+>   You however cannot use variables defined under `script`.
 
 For example:
 
@@ -799,13 +800,13 @@ as Review Apps. You can see a simple example using Review Apps at
 
 ## `cache`
 
+> **Notes:**
 >
-**Notes:**
-- Introduced in GitLab Runner v0.7.0.
-- `cache` can be set globally and per-job.
-- From GitLab 9.0, caching is enabled and shared between pipelines and jobs
-  by default.
-- From GitLab 9.2, caches are restored before [artifacts](#artifacts).
+> - Introduced in GitLab Runner v0.7.0.
+> - `cache` can be set globally and per-job.
+> - From GitLab 9.0, caching is enabled and shared between pipelines and jobs
+>   by default.
+> - From GitLab 9.2, caches are restored before [artifacts](#artifacts).
 
 TIP: **Learn more:**
 Read how caching works and find out some good practices in the
@@ -967,13 +968,13 @@ skip the download step.
 
 ## `artifacts`
 
+> **Notes:**
 >
-**Notes:**
-- Introduced in GitLab Runner v0.7.0 for non-Windows platforms.
-- Windows support was added in GitLab Runner v.1.0.0.
-- From GitLab 9.2, caches are restored before artifacts.
-- Not all executors are [supported](https://docs.gitlab.com/runner/executors/#compatibility-chart).
-- Job artifacts are only collected for successful jobs by default.
+> - Introduced in GitLab Runner v0.7.0 for non-Windows platforms.
+> - Windows support was added in GitLab Runner v.1.0.0.
+> - From GitLab 9.2, caches are restored before artifacts.
+> - Not all executors are [supported](https://docs.gitlab.com/runner/executors/#compatibility-chart).
+> - Job artifacts are only collected for successful jobs by default.
 
 `artifacts` is used to specify a list of files and directories which should be
 attached to the job after success.

doc/development/background_migrations.md

@@ -10,10 +10,10 @@ migrations automatically reschedule themselves for a later point in time.
 
 ## When To Use Background Migrations
 
->**Note:**
-When adding background migrations _you must_ make sure they are announced in the
-monthly release post along with an estimate of how long it will take to complete
-the migrations.
+> **Note:**
+> When adding background migrations _you must_ make sure they are announced in the
+> monthly release post along with an estimate of how long it will take to complete
+> the migrations.
 
 In the vast majority of cases you will want to use a regular Rails migration
 instead. Background migrations should _only_ be used when migrating _data_ in

doc/development/contributing/issue_workflow.md

@@ -250,7 +250,7 @@ code snippet right after your description in a new line: `~"feature proposal"`.
 Please keep feature proposals as small and simple as possible, complex ones
 might be edited to make them small and simple.
 
-Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Feature Proposal.md) provided on the issue tracker.
+Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Feature%20Proposal.md) provided on the issue tracker.
 
 For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should
 be given the ~"UX" label. This will allow the UX team to provide input and guidance. You may

doc/development/contributing/merge_request_workflow.md

@@ -138,7 +138,7 @@ When having your code reviewed and when reviewing merge requests please take the
    making and testing future changes
 1. Changes do not adversely degrade performance.
    - Avoid repeated polling of endpoints that require a significant amount of overhead
-   - Check for N+1 queries via the SQL log or [`QueryRecorder`](https://docs.gitlab.com/ce/development/mer ge_request_performance_guidelines.html)
+   - Check for N+1 queries via the SQL log or [`QueryRecorder`](https://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
    - Avoid repeated access of filesystem
 1. If you need polling to support real-time features, please use
    [polling with ETag caching][polling-etag].

doc/development/documentation/styleguide.md

@@ -297,10 +297,10 @@ avoid duplication, link to the special document that can be found in
 [`doc/administration/restart_gitlab.md`][doc-restart]. Usually the text will
 read like:
 
-  ```
-  Save the file and [reconfigure GitLab](../../administration/restart_gitlab.md)
-  for the changes to take effect.
-  ```
+```
+Save the file and [reconfigure GitLab](../../administration/restart_gitlab.md)
+for the changes to take effect.
+```
 
 If the document you are editing resides in a place other than the GitLab CE/EE
 `doc/` directory, instead of the relative link, use the full path:

doc/development/ee_features.md

@@ -166,7 +166,8 @@ There are a few gotchas with it:
   to make it call the other method we want to extend, like a [template method
   pattern](https://en.wikipedia.org/wiki/Template_method_pattern).
   For example, given this base:
-  ``` ruby
+
+    ```ruby
       class Base
         def execute
           return unless enabled?
@@ -176,9 +177,11 @@ There are a few gotchas with it:
         end
       end
     ```
+
     Instead of just overriding `Base#execute`, we should update it and extract
     the behaviour into another method:
-  ``` ruby
+
+    ```ruby
       class Base
         def execute
           return unless enabled?
@@ -194,9 +197,11 @@ There are a few gotchas with it:
         end
       end
     ```
+
     Then we're free to override that `do_something` without worrying about the
     guards:
-  ``` ruby
+
+    ```ruby
       module EE::Base
         extend ::Gitlab::Utils::Override
   
@@ -206,6 +211,7 @@ There are a few gotchas with it:
         end
       end
     ```
+  
     This would require updating CE first, or make sure this is back ported to CE.
 
 When prepending, place them in the `ee/` specific sub-directory, and
@@ -469,7 +475,7 @@ Put the EE module files following
 
 For EE API routes, we put them in a `prepended` block:
 
-``` ruby
+```ruby
 module EE
   module API
     module MergeRequests
@@ -503,7 +509,7 @@ interface first here.
 For example, suppose we have a few more optional params for EE, given this CE
 API code:
 
-``` ruby
+```ruby
 module API
   class MergeRequests < Grape::API
     # EE::API::MergeRequests would override the following helpers
@@ -525,7 +531,7 @@ end
 
 And then we could override it in EE module:
 
-``` ruby
+```ruby
 module EE
   module API
     module MergeRequests
@@ -552,7 +558,7 @@ To make it easy for an EE module to override the CE helpers, we need to define
 those helpers we want to extend first. Try to do that immediately after the
 class definition to make it easy and clear:
 
-``` ruby
+```ruby
 module API
   class JobArtifacts < Grape::API
     # EE::API::JobArtifacts would override the following helpers
@@ -569,7 +575,7 @@ end
 
 And then we can follow regular object-oriented practices to override it:
 
-``` ruby
+```ruby
 module EE
   module API
     module JobArtifacts
@@ -596,7 +602,7 @@ therefore can't be simply overridden. We need to extract them into a standalone
 method, or introduce some "hooks" where we could inject behavior in the CE
 route. Something like this:
 
-``` ruby
+```ruby
 module API
   class MergeRequests < Grape::API
     helpers do
@@ -623,7 +629,7 @@ end
 Note that `update_merge_request_ee` doesn't do anything in CE, but
 then we could override it in EE:
 
-``` ruby
+```ruby
 module EE
   module API
     module MergeRequests
@@ -662,7 +668,7 @@ For example, in one place we need to pass an extra argument to
 `at_least_one_of` so that the API could consider an EE-only argument as the
 least argument. This is not quite beautiful but it's working:
 
-``` ruby
+```ruby
 module API
   class MergeRequests < Grape::API
     def self.update_params_at_least_one_of
@@ -683,7 +689,7 @@ end
 
 And then we could easily extend that argument in the EE class method:
 
-``` ruby
+```ruby
 module EE
   module API
     module MergeRequests

doc/development/fe_guide/performance.md

@@ -74,7 +74,7 @@ bundle and included on the page.
 > `content_for :page_specific_javascripts` within haml files, along with
 > manually generated webpack bundles. However under this new system you should
 > not ever need to manually add an entry point to the `webpack.config.js` file.
-
+>
 > **Tip:**
 > If you are unsure what controller and action corresponds to a given page, you
 > can find this out by inspecting `document.body.dataset.page` within your
@@ -109,7 +109,6 @@ bundle and included on the page.
       `my_widget.js` is only imported within `pages/widget/show/index.js`, you
       should place the module at `pages/widget/show/my_widget.js` and import it
       with a relative path (e.g. `import initMyWidget from './my_widget';`).
-
     - If a class or module is _used by multiple routes_, place it within a
       shared directory at the closest common parent directory for the entry
       points that import it.  For example, if `my_widget.js` is imported within

doc/development/fe_guide/vuex.md

@@ -290,6 +290,7 @@ export default {
 ```
 
 ### Vuex Gotchas
+
 1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency throughout the application. From Vuex docs:
 
     >  why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action.

doc/development/gotchas.md

@@ -101,8 +101,10 @@ end
   in a prepended module, which is very likely the case in EE. We could see
   error like this:
 
+    ```
     1.1) Failure/Error: allow_any_instance_of(ApplicationSetting).to receive_messages(messages)
          Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
+    ```
 
 ### Alternative: `expect_next_instance_of`
 

doc/development/i18n/proofreader.md

@@ -65,7 +65,6 @@ are very appreciative of the work done by translators and proofreaders!
 
     Add your language in alphabetical order, and add yourself to the list
     including:
-
     - name
     - link to your GitLab profile
     - link to your CrowdIn profile

doc/development/new_fe_guide/development/testing.md

@@ -6,7 +6,7 @@
   * **[Ruby unit tests](#ruby-unit-tests-spec-rb)** for models, controllers, helpers, etc. (`/spec/**/*.rb`)
   * **[Full feature tests](#full-feature-tests-spec-features-rb)** (`/spec/features/**/*.rb`)
 * **[Karma](#karma-tests-spec-javascripts-js)** (`/spec/javascripts/**/*.js`)
-* ~~Spinach~~ — These have been removed from our codebase in May 2018. (`/features/`)
+* <s>Spinach</s> — These have been removed from our codebase in May 2018. (`/features/`)
 
 ## RSpec: Ruby unit tests `/spec/**/*.rb`
 

doc/development/new_fe_guide/style/javascript.md

@@ -12,34 +12,34 @@ You can run eslint locally by running `yarn eslint`
 <a name="avoid-foreach"></a><a name="1.1"></a>
 - [1.1](#avoid-foreach) **Avoid ForEach when mutating data** Use `map`, `reduce` or `filter` instead of `forEach` when mutating data. This will minimize mutations in functions ([which is aligned with Airbnb's style guide][airbnb-minimize-mutations])
 
-```
-// bad
-users.forEach((user, index) => {
+    ```
+    // bad
+    users.forEach((user, index) => {
       user.id = index;
-});
+    });
     
-// good
-const usersWithId = users.map((user, index) => {
+    // good
+    const usersWithId = users.map((user, index) => {
       return Object.assign({}, user, { id: index });
-});
-```
+    });
+    ```
 
 ## Functions
 
 <a name="limit-params"></a><a name="2.1"></a>
 - [2.1](#limit-params) **Limit number of parameters** If your function or method has more than 3 parameters, use an object as a parameter instead.
 
-```
-// bad
-function a(p1, p2, p3) {
+    ```
+    // bad
+    function a(p1, p2, p3) {
       // ...
-};
+    };
     
-// good
-function a(p) {
+    // good
+    function a(p) {
       // ...
-};
-```
+    };
+    ```
 
 ## Classes & constructors
 
@@ -73,9 +73,9 @@ function a(p) {
 <a name="avoid-classes-to-handle-dom-events"></a><a name="3.2"></a>
 - [3.2](#avoid-classes-to-handle-dom-events) **Avoid classes to handle DOM events** If the only purpose of the class is to bind a DOM event and handle the callback, prefer using a function.
 
-```
-// bad
-class myClass {
+    ```
+    // bad
+    class myClass {
       constructor(config) {
         this.config = config;
       }
@@ -83,87 +83,86 @@ class myClass {
       init() {
         document.addEventListener('click', () => {});
       }
-}
+    }
     
-// good
+    // good
     
-const myFunction = () => {
+    const myFunction = () => {
       document.addEventListener('click', () => {
         // handle callback here
       });
-}
-```
+    }
+    ```
 
 <a name="element-container"></a><a name="3.3"></a>
 - [3.3](#element-container) **Pass element container to constructor** When your class manipulates the DOM, receive the element container as a parameter.
 This is more maintainable and performant.
 
-```
-// bad
-class a {
+    ```
+    // bad
+    class a {
       constructor() {
         document.querySelector('.b');
       }
-}
+    }
     
-// good
-class a {
+    // good
+    class a {
       constructor(options) {
         options.container.querySelector('.b');
       }
-}
-```
+    }
+    ```
 
 ## Type Casting & Coercion
 
 <a name="use-parseint"></a><a name="4.1"></a>
 - [4.1](#use-parseint) **Use ParseInt** Use `ParseInt` when converting a numeric string into a number.
 
-```
-// bad
-Number('10')
-
+    ```
+    // bad
+    Number('10')
     
-// good
-parseInt('10', 10);
-```
+    // good
+    parseInt('10', 10);
+    ```
 
 ## CSS Selectors
 
 <a name="use-js-prefix"></a><a name="5.1"></a>
 - [5.1](#use-js-prefix) **Use js prefix** If a CSS class is only being used in JavaScript as a reference to the element, prefix the class name with `js-`
 
-```
-// bad
-<button class="add-user"></button>
+    ```
+    // bad
+    <button class="add-user"></button>
     
-// good
-<button class="js-add-user"></button>
-```
+    // good
+    <button class="js-add-user"></button>
+    ```
 
 ## Modules
 
 <a name="use-absolute-paths"></a><a name="6.1"></a>
 - [6.1](#use-absolute-paths) **Use absolute paths for nearby modules** Use absolute paths if the module you are importing is less than two levels up.
 
-```
-// bad
-import GitLabStyleGuide from '~/guides/GitLabStyleGuide';
+    ```
+    // bad
+    import GitLabStyleGuide from '~/guides/GitLabStyleGuide';
     
-// good
-import GitLabStyleGuide from '../GitLabStyleGuide';
-```
+    // good
+    import GitLabStyleGuide from '../GitLabStyleGuide';
+    ```
 
 <a name="use-relative-paths"></a><a name="6.2"></a>
 - [6.2](#use-relative-paths) **Use relative paths for distant modules** If the module you are importing is two or more levels up, use a relative path instead of an absolute path.
 
-```
-// bad
-import GitLabStyleGuide from '../../../guides/GitLabStyleGuide';
+    ```
+    // bad
+    import GitLabStyleGuide from '../../../guides/GitLabStyleGuide';
     
-// good
-import GitLabStyleGuide from '~/GitLabStyleGuide';
-```
+    // good
+    import GitLabStyleGuide from '~/GitLabStyleGuide';
+    ```
 
 <a name="global-namespace"></a><a name="6.3"></a>
 - [6.3](#global-namespace) **Do not add to global namespace**

doc/development/sidekiq_debugging.md

@@ -3,8 +3,7 @@
 ## Log arguments to Sidekiq jobs
 
 If you want to see what arguments are being passed to Sidekiq jobs you can set
-the `SIDEKIQ_LOG_ARGUMENTS` [environment variable]
-(https://docs.gitlab.com/omnibus/settings/environment-variables.html) to `1` (true).
+the `SIDEKIQ_LOG_ARGUMENTS` [environment variable](https://docs.gitlab.com/omnibus/settings/environment-variables.html) to `1` (true).
 
 Example:
 

doc/development/testing_guide/ci.md

@@ -12,7 +12,7 @@ Our current CI parallelization setup is as follows:
    distributed share of tests:
    - It works because the jobs have access to the
      `knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` since the "artifacts
-    from all previous stages are passed by default". [^1]
+     from all previous stages are passed by default".
    - the jobs set their own report path to
      `KNAPSACK_REPORT_PATH=knapsack/${CI_PROJECT_NAME}/${JOB_NAME[0]}_node_${CI_NODE_INDEX}_${CI_NODE_TOTAL}_report.json`.
    - if knapsack is doing its job, test files that are run should be listed under

doc/development/testing_guide/testing_levels.md

@@ -153,7 +153,7 @@ trade-off:
 - Unit tests are usually cheap, and you should consider them like the basement
   of your house: you need them to be confident that your code is behaving
   correctly. However if you run only unit tests without integration / system
-  tests, you might [miss] the [big] [picture]!
+  tests, you might [miss] the [big] / [picture] !
 - Integration tests are a bit more expensive, but don't abuse them. A system test
   is often better than an integration test that is stubbing a lot of internals.
 - System tests are expensive (compared to unit tests), even more if they require

doc/gitlab-basics/create-project.md

 # How to create a project in GitLab
 
->**Notes:**
-- For a list of words that are not allowed to be used as project names see the
-  [reserved names][reserved].
+> **Notes:**
+> - For a list of words that are not allowed to be used as project names see the
+>   [reserved names][reserved].
 
 1. In your dashboard, click the green **New project** button or use the plus
    icon in the upper right corner of the navigation bar.

doc/install/azure/index.md

@@ -71,7 +71,7 @@ The first items we need to configure are the basic settings of the underlying vi
 1. Enter a `User name` - e.g. **"gitlab-admin"**
 1. Select an `Authentication type`, either **SSH public key** or **Password**:
     
-    >**Note:** if you're unsure which authentication type to use, select **Password**
+    > **Note:** if you're unsure which authentication type to use, select **Password**
 
     1. If you chose **SSH public key** - enter your `SSH public key` into the field provided 
     _(read the [SSH documentation][GitLab-Docs-SSH] to learn more about how to setup SSH 
@@ -80,8 +80,10 @@ The first items we need to configure are the basic settings of the underlying vi
     will use later in this tutorial to [SSH] into the VM, so make sure it's a strong password/passphrase)_
 1. Choose the appropriate `Subscription` tier for your Azure account
 1. Choose an existing `Resource Group` or create a new one - e.g. **"GitLab-CE-Azure"**
->**Note:** a "Resource group" is a way to group related resources together for easier administration. 
-We chose "GitLab-CE-Azure", but your resource group can have the same name as your VM.
+
+    > **Note:** a "Resource group" is a way to group related resources together for easier administration. 
+    > We chose "GitLab-CE-Azure", but your resource group can have the same name as your VM.
+
 1. Choose a `Location` - if you're unsure, select the default location
 
 Here are the settings we've used:
@@ -95,7 +97,7 @@ Check the settings you have entered, and then click **"OK"** when you're ready t
 Next, you need to choose the size of your VM - selecting features such as the number of CPU cores, 
 the amount of RAM, the size of storage (and its speed), etc.
 
->**Note:** in common with other cloud vendors, Azure operates a resource/usage pricing model, i.e. 
+> **Note:** in common with other cloud vendors, Azure operates a resource/usage pricing model, i.e. 
 the more resources your VM consumes the more it will cost you to run, so make your selection 
 carefully. You'll see that Azure provides an _estimated_ monthly cost beneath each VM Size to help
 guide your selection.
@@ -106,7 +108,7 @@ ahead and select this one, but please choose the size which best meets your own
 
 ![Azure - Create Virtual Machine - Size](img/azure-create-virtual-machine-size.png)
 
->**Note:** be aware that whilst your VM is active (known as "allocated"), it will incur 
+> **Note:** be aware that whilst your VM is active (known as "allocated"), it will incur 
 "compute charges" which, ultimately, you will be billed for. So, even if you're using the 
 free trial credits, you'll likely want to learn 
 [how to properly shutdown an Azure VM to save money][Azure-Properly-Shutdown-VM].
@@ -132,7 +134,7 @@ new VM. You'll be billed only for the VM itself (e.g. "Standard DS1 v2") because
 
 ![Azure - Create Virtual Machine - Purchase](img/azure-create-virtual-machine-purchase.png)
 
->**Note:** at this stage, you can review and modify the any of the settings you have made during all 
+> **Note:** at this stage, you can review and modify the any of the settings you have made during all 
 previous steps, just click on any of the four steps to re-open them.
 
 When you have read and agreed to the terms of use and are ready to proceed, click **"Purchase"**.
@@ -174,7 +176,7 @@ _(the full domain name of your own VM will be different, of course)_.
 
 Click **"Save"** for the changes to take effect.
 
->**Note:** if you want to use your own domain name, you will need to add a DNS `A` record at your 
+> **Note:** if you want to use your own domain name, you will need to add a DNS `A` record at your 
 domain registrar which points to the public IP address of your Azure VM. If you do this, you'll need 
 to make sure your VM is configured to use a _static_ public IP address (i.e. not a _dynamic_ one) 
 or you will have to reconfigure the DNS `A` record each time Azure reassigns your VM a new public IP 
@@ -190,7 +192,7 @@ Ports are opened by adding _security rules_ to the **"Network security group"**
 has been assigned to. If you followed the process above, then Azure will have automatically created 
 an NSG named `GitLab-CE-nsg` and assigned the `GitLab-CE` VM to it. 
 
->**Note:** if you gave your VM a different name then the NSG automatically created by Azure will 
+> **Note:** if you gave your VM a different name then the NSG automatically created by Azure will 
 also have a different name - the name you have your VM, with `-nsg` appended to it.
 
 You can navigate to the NSG settings via many different routes in the Azure Portal, but one of the 
@@ -321,7 +323,7 @@ Under the **"Components"** section, we can see that our VM is currently running
 GitLab. This is the version of GitLab which was contained in the Azure Marketplace 
 **"GitLab Community Edition"** offering we used to build the VM when we wrote this tutorial. 
 
->**Note:** The version of GitLab in your own VM instance may well be different, but the update 
+> **Note:** The version of GitLab in your own VM instance may well be different, but the update 
 process will still be the same.
 
 ### Connect via SSH
@@ -333,11 +335,11 @@ connect to it using SSH ([Secure Shell][SSH]).
 If you're running Windows, you'll need to connect using [PuTTY] or an equivalent Windows SSH client. 
 If you're running Linux or macOS, then you already have an SSH client installed. 
 
->**Note:** 
-- Remember that you will need to login with the username and password you specified 
-[when you created](#basics) your Azure VM
-- If you need to reset your VM password, read 
-[how to reset SSH credentials for a user on an Azure VM][Azure-Troubleshoot-SSH-Connection].
+> **Note:** 
+> - Remember that you will need to login with the username and password you specified 
+>   [when you created](#basics) your Azure VM
+> - If you need to reset your VM password, read 
+>   [how to reset SSH credentials for a user on an Azure VM][Azure-Troubleshoot-SSH-Connection].
 
 #### SSH from the command-line
 

doc/install/database_mysql.md

 # Database MySQL
 
->**Note:**
-- We do not recommend using MySQL due to various issues. For example, case
-[(in)sensitivity](https://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html)
-and [problems](https://bugs.mysql.com/bug.php?id=65830) that
-[suggested](https://bugs.mysql.com/bug.php?id=50909)
-[fixes](https://bugs.mysql.com/bug.php?id=65830) [have](https://bugs.mysql.com/bug.php?id=63164).
+> **Note:**
+> - We do not recommend using MySQL due to various issues. For example, case
+    [(in)sensitivity](https://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html)
+    and [problems](https://bugs.mysql.com/bug.php?id=65830) that
+    [suggested](https://bugs.mysql.com/bug.php?id=50909)
+    [fixes](https://bugs.mysql.com/bug.php?id=65830) [have](https://bugs.mysql.com/bug.php?id=63164).
 
 ## Initial database setup
 
@@ -146,10 +146,12 @@ Congrats, your GitLab database uses the right InnoDB tablespace format.
 However, you must still ensure that any **future tables** created by GitLab will still use the right format:
 
 - If `SELECT @@innodb_file_per_table` returned **1** previously, your server is running correctly.
-> It's however a requirement to check *now* that this setting is indeed persisted in your [my.cnf](https://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) file!
+
+    > It's however a requirement to check *now* that this setting is indeed persisted in your [my.cnf](https://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) file!
 
 - If `SELECT @@innodb_file_per_table` returned **0** previously, your server is not running correctly.
-> [Enable innodb_file_per_table](https://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) by running in a MySQL session as root the command `SET GLOBAL innodb_file_per_table=1, innodb_file_format=Barracuda;` and persist the two settings in your [my.cnf](https://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) file
+
+    > [Enable innodb_file_per_table](https://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) by running in a MySQL session as root the command `SET GLOBAL innodb_file_per_table=1, innodb_file_format=Barracuda;` and persist the two settings in your [my.cnf](https://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) file
 
 Now, if you have a **different result** returned by the 2 commands above, it means you have a **mix of tables format** uses in your GitLab database. This can happen if your MySQL server had different values for `innodb_file_per_table` in its life and you updated GitLab at different moments with those inconsistent values. So keep reading.
 

doc/install/openshift_and_gitlab/index.md

@@ -63,9 +63,11 @@ what we will use in this tutorial.
 In short:
 
 1. Open a terminal and in a new directory run:
+
     ```sh
     vagrant init openshift/origin-all-in-one
     ```
+
 1. This will generate a Vagrantfile based on the all-in-one VM image
 1. In the same directory where you generated the Vagrantfile
    enter:
@@ -469,6 +471,7 @@ GitLab service account to the `anyuid` [Security Context Constraints][scc].
 For OpenShift v3.0, you will need to do this manually:
 
 1. Edit the Security Context:
+
     ```sh
     oc edit scc anyuid
     ```

doc/integration/azure.md

@@ -2,7 +2,7 @@
 
 To enable the Microsoft Azure OAuth2 OmniAuth provider you must register your application with Azure. Azure will generate a client ID and secret key for you to use.
 
-1.  Sign in to the [Azure Management Portal](https://manage.windowsazure.com>).
+1.  Sign in to the [Azure Management Portal](https://manage.windowsazure.com).
 
 1.  Select "Active Directory" on the left and choose the directory you want to use to register GitLab.
 

doc/integration/omniauth.md

@@ -50,16 +50,16 @@ that are in common for all providers that we need to consider.
   be blocked by default and will have to be unblocked by an administrator before
   they are able to sign in.
 
->**Note:**
-If you set `block_auto_created_users` to `false`, make sure to only
-define providers under `allow_single_sign_on` that you are able to control, like
-SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
-the Internet will be able to successfully sign in to your GitLab without
-administrative approval.
-
->**Note:**
-`auto_link_ldap_user` requires the `uid` of the user to be the same in both LDAP
-and the OmniAuth provider.
+> **Note:**
+> If you set `block_auto_created_users` to `false`, make sure to only
+> define providers under `allow_single_sign_on` that you are able to control, like
+> SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
+> the Internet will be able to successfully sign in to your GitLab without
+> administrative approval.
+>
+> **Note:**
+> `auto_link_ldap_user` requires the `uid` of the user to be the same in both LDAP
+> and the OmniAuth provider.
 
 To change these settings:
 
@@ -233,15 +233,15 @@ You can enable profile syncing from selected OmniAuth providers and for all or f
 
 When authenticating using LDAP, the user's email is always synced.
 
- ```ruby
+```ruby
   gitlab_rails['sync_profile_from_provider'] = ['twitter', 'google_oauth2']
   gitlab_rails['sync_profile_attributes'] = ['name', 'email', 'location']
  ```
 
- **For installations from source**
+**For installations from source**
 
- ```yaml
+```yaml
   omniauth:
     sync_profile_from_provider: ['twitter', 'google_oauth2']
     sync_profile_attributes: ['email', 'location']
- ```
+```

doc/integration/saml.md

@@ -123,9 +123,10 @@ in your SAML IdP:
 To ease configuration, most IdP accept a metadata URL for the application to provide
 configuration information to the IdP. To build the metadata URL for GitLab, append
 `users/auth/saml/metadata` to the HTTPS URL of your GitLab installation, for instance:
-   ```
-   https://gitlab.example.com/users/auth/saml/metadata
-   ```
+
+```
+https://gitlab.example.com/users/auth/saml/metadata
+```
 
 At a minimum the IdP *must* provide a claim containing the user's email address, using
 claim name `email` or `mail`. The email will be used to automatically generate the GitLab

doc/topics/git/numerous_undo_possibilities_in_git/index.md

@@ -41,7 +41,6 @@ Here's what we'll cover in this tutorial:
     - [Without history modification](#undo-remote-changes-without-changing-history) (preferred way)
     - [With history modification](#undo-remote-changes-with-modifying-history) (requires
       coordination with team and force pushes).
-
        - [Usecases when modifying history is generally acceptable](#where-modifying-history-is-generally-acceptable)
        - [How to modify history](#how-modifying-history-is-done)
        - [How to remove sensitive information from repository](#deleting-sensitive-information-from-commits)
@@ -101,25 +100,24 @@ no changes added to commit (use "git add" and/or "git commit -a")
 
 At this point there are 3 options to undo the local changes you have:
 
- - Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes)
+- Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes)
 
     ```shell
     git stash
     ```
 
- - Discarding local changes (permanently) to a file
+- Discarding local changes (permanently) to a file
 
     ```shell
     git checkout -- <file>
     ```
 
- - Discard all local changes to all files permanently
+- Discard all local changes to all files permanently
 
     ```shell
     git reset --hard
     ```
 
-
 Before executing `git reset --hard`, keep in mind that there is also a way to
 just temporary store the changes without committing them using `git stash`.
 This command resets the changes to all files, but it also saves them in case
@@ -140,10 +138,10 @@ them. This is achieved by Git stashing command `git stash`, which in fact saves
 current work and runs `git reset --hard`, but it also has various
 additional options like:
 
- - `git stash save`, which enables including temporary commit message, which will help you identify changes, among with other options
- - `git stash list`, which lists all previously stashed commits (yes, there can be more) that were not `pop`ed
- - `git stash pop`, which redoes previously stashed changes and removes them from stashed list
- - `git stash apply`, which redoes previously stashed changes, but keeps them on stashed list
+- `git stash save`, which enables including temporary commit message, which will help you identify changes, among with other options
+- `git stash list`, which lists all previously stashed commits (yes, there can be more) that were not `pop`ed
+- `git stash pop`, which redoes previously stashed changes and removes them from stashed list
+- `git stash apply`, which redoes previously stashed changes, but keeps them on stashed list
 
 ### Staged local changes (before you commit)
 
@@ -174,25 +172,25 @@ Changes to be committed:
 
 Now you have 4 options to undo your changes:
 
- - Unstage the file to current commit (HEAD)
+- Unstage the file to current commit (HEAD)
 
     ```shell
     git reset HEAD <file>
     ```
 
- - Unstage everything - retain changes
+- Unstage everything - retain changes
 
     ```shell
     git reset
     ```
 
- - Discard all local changes, but save them for [later](#quickly-save-local-changes)
+- Discard all local changes, but save them for [later](#quickly-save-local-changes)
 
     ```shell
     git stash
     ```
 
- - Discard everything permanently
+- Discard everything permanently
 
     ```shell
     git reset --hard
@@ -248,7 +246,7 @@ In our example we will end up with commit `B`, that introduced bug/error. We hav
     git reset  commit-B-id <file>
     ```
 
- - There is one command we also must not forget: **creating a new branch**
+- There is one command we also must not forget: **creating a new branch**
   from the point where changes are not applicable or where the development has hit a
   dead end. For example you have done commits `A-B-C-D` on your feature-branch
   and then you figure `C` and `D` are wrong. At this point you either reset to `B`

doc/university/high-availability/aws/README.md

@@ -395,5 +395,5 @@ some redundancy options but it might also imply Geographic replication.
 There is a lot of ground yet to cover so have a read through these other
 resources and feel free to open an issue to request additional material.
 
- * [GitLab High Availability](http://docs.gitlab.com/ce/administration/high_availability/README.html#sts=High Availability)
- * [GitLab Geo](http://docs.gitlab.com/ee/gitlab-geo/README.html)  
+* [GitLab High Availability](http://docs.gitlab.com/ce/administration/high_availability/README.html#sts=High%20Availability)
+* [GitLab Geo](http://docs.gitlab.com/ee/gitlab-geo/README.html)  

doc/university/training/topics/getting_started.md

@@ -9,13 +9,15 @@ comments: false
 ## Instantiating Repositories
 
 * Create a new repository by instantiating it through
-```bash
-git init
-```
+
+    ```bash
+    git init
+    ```
 * Copy an existing project by cloning the repository through
-```bash
-git clone <url>
-```
+
+    ```bash
+    git clone <url>
+    ```
 
 ----------
 
@@ -24,9 +26,10 @@ git clone <url>
 * To instantiate a central repository a `--bare` flag is required.
 * Bare repositories don't allow file editing or committing changes.
 * Create a bare repo with
-```bash
-git init --bare project-name.git
-```
+
+    ```bash
+    git init --bare project-name.git
+    ```
 
 ----------
 

doc/university/training/topics/git_add.md

@@ -11,27 +11,35 @@ comments: false
 Adds content to the index or staging area.
 
 * Adds a list of file
-```bash
-git add <files>
-```
+
+    ```bash
+    git add <files>
+    ```
+
 * Adds all files including deleted ones
-```bash
-git add -A
-```
+
+    ```bash
+    git add -A
+    ```
 
 ----------
 
 ## Git add continued
 
 * Add all text files in current dir
-```bash
-git add *.txt
-```
+
+    ```bash
+    git add *.txt
+    ```
+
 * Add all text file in the project
-```bash
-git add "*.txt*"
-```
+
+    ```bash
+    git add "*.txt*"
+    ```
+
 * Adds all files in directory
-```bash
-git add views/layouts/
-```
+
+    ```bash
+    git add views/layouts/
+    ```

doc/university/training/topics/git_log.md

@@ -9,31 +9,36 @@ comments: false
 Git log lists commit history. It allows searching and filtering.
 
 * Initiate log
-```
-git log
-```
+
+    ```
+    git log
+    ```
 
 * Retrieve set number of records:
-```
-git log -n 2
-```
+
+    ```
+    git log -n 2
+    ```
 
 * Search commits by author. Allows user name or a regular expression.
-```
-git log --author="user_name"
-```
+
+    ```
+    git log --author="user_name"
+    ```
 
 ----------
 
 * Search by comment message.
-```
-git log --grep="<pattern>"
-```
+
+    ```
+    git log --grep="<pattern>"
+    ```
 
 * Search by date
-```
-git log --since=1.month.ago --until=3.weeks.ago
-```
+
+    ```
+    git log --since=1.month.ago --until=3.weeks.ago
+    ```
 
 
 ----------

doc/university/training/topics/rollback_commits.md

@@ -9,26 +9,30 @@ comments: false
 ## Undo Commits
 
 * Undo last commit putting everything back into the staging area.
-```
-git reset --soft HEAD^
-```
+
+    ```
+    git reset --soft HEAD^
+    ```
 
 * Add files and change message with:
-```
-git commit --amend -m "New Message"
-```
+
+    ```
+    git commit --amend -m "New Message"
+    ```
 
 ----------
 
 * Undo last and remove changes
-```
-git reset --hard HEAD^
-```
+
+    ```
+    git reset --hard HEAD^
+    ```
 
 * Same as last one but for two commits back
-```
-git reset --hard HEAD^^
-```
+
+    ```
+    git reset --hard HEAD^^
+    ```
 
 ** Don't reset after pushing **
 

doc/university/training/topics/stash.md

@@ -10,50 +10,52 @@ We use git stash to store our changes when they are not ready to be committed
 and we need to change to a different branch.
 
 * Stash
-```
-git stash save
-# or
-git stash
-# or with a message
-git stash save "this is a message to display on the list"
-```
+
+    ```
+    git stash save
+    # or
+    git stash
+    # or with a message
+    git stash save "this is a message to display on the list"
+    ```
 
 * Apply stash to keep working on it
-```
-git stash apply
-# or apply a specific one from out stack
-git stash apply stash@{3}
-```
+
+    ```
+    git stash apply
+    # or apply a specific one from out stack
+    git stash apply stash@{3}
+    ```
 
 ----------
 
 * Every time we save a stash it gets stacked so by using list we can see all our
 stashes.
 
-```
-git stash list
-# or for more information (log methods)
-git stash list --stat
-```
+    ```
+    git stash list
+    # or for more information (log methods)
+    git stash list --stat
+    ```
 
 * To clean our stack we need to manually remove them.
 
-```
-# drop top stash
-git stash drop
-# or
-git stash drop <name>
-# to clear all history we can use
-git stash clear
-```
+    ```
+    # drop top stash
+    git stash drop
+    # or
+    git stash drop <name>
+    # to clear all history we can use
+    git stash clear
+    ```
 
 ----------
 
 * Apply and drop on one command
 
-```
+    ```
       git stash pop
-```
+    ```
 
 * If we meet conflicts we need to either reset or commit our changes.
 

doc/university/training/topics/unstage.md

@@ -10,26 +10,27 @@ comments: false
 
 * To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch.
 
-```bash
-git reset HEAD <file>
-```
+    ```bash
+    git reset HEAD <file>
+    ```
 
 * This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use:
 
-```bash
-git checkout -- <file>
-```
+    ```bash
+    git checkout -- <file>
+    ```
 
 ----------
 
 * To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag.
-```
-git rm '*.txt'
-git rm -r <dirname>
-```
 
+    ```
+    git rm '*.txt'
+    git rm -r <dirname>
+    ```
 
 * If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`.
-```
-git rm <filename> --cache
-```
+
+    ```
+    git rm <filename> --cache
+    ```

doc/user/admin_area/monitoring/health_check.md

 # Health Check
 
->**Notes:**
-  - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
-  - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will
-    be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior)
-    section.
-  - [Access token](#access-token) has been deprecated in GitLab 9.4
-    in favor of [IP whitelist](#ip-whitelist)
+> **Notes:**
+>   - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
+>   - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will
+>     be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior)
+>     section.
+>   - [Access token](#access-token) has been deprecated in GitLab 9.4
+>     in favor of [IP whitelist](#ip-whitelist)
 
 GitLab provides liveness and readiness probes to indicate service health and
 reachability to required services. These probes report on the status of the

doc/user/award_emojis.md

 # Award emoji
 
->**Notes:**
-- First [introduced][1825] in GitLab 8.2.
-- GitLab 9.0 [introduced][ce-9570] the usage of native emojis if the platform
-  supports them and falls back to images or CSS sprites. This change greatly
-  improved the award emoji performance overall.
+> **Notes:**
+> - First [introduced][1825] in GitLab 8.2.
+> - GitLab 9.0 [introduced][ce-9570] the usage of native emojis if the platform
+>  supports them and falls back to images or CSS sprites. This change greatly
+>  improved the award emoji performance overall.
 
 When you're collaborating online, you get fewer opportunities for high-fives
 and thumbs-ups. Emoji can be awarded to issues, merge requests, snippets, and

doc/user/discussions/index.md

@@ -23,9 +23,9 @@ in the form of a resolvable or threaded discussion.
 
 ## Resolvable discussions
 
->**Notes:**
-- The main feature was [introduced][ce-5022] in GitLab 8.11.
-- Resolvable discussions can be added only to merge request diffs.
+> **Notes:**
+> - The main feature was [introduced][ce-5022] in GitLab 8.11.
+> - Resolvable discussions can be added only to merge request diffs.
 
 Discussion resolution helps keep track of progress during planning or code review.
 Resolving comments prevents you from forgetting to address feedback and lets you

doc/user/group/index.md

@@ -64,8 +64,8 @@ together in a single list view.
 ## Create a new group
 
 > **Notes:**
-- For a list of words that are not allowed to be used as group names see the
-  [reserved names](../reserved_names.md).
+> - For a list of words that are not allowed to be used as group names see the
+>   [reserved names](../reserved_names.md).
 
 You can create a group in GitLab from:
 

doc/user/group/subgroups/index.md

 # Subgroups
 
->**Notes:**
-- [Introduced][ce-2772] in GitLab 9.0.
-- Not available when using MySQL as external database (support removed in
-  GitLab 9.3 [due to performance reasons][issue]).
+> **Notes:**
+> - [Introduced][ce-2772] in GitLab 9.0.
+> - Not available when using MySQL as external database (support removed in
+>   GitLab 9.3 [due to performance reasons][issue]).
 
 With subgroups (aka nested groups or hierarchical groups) you can have
 up to 20 levels of nested groups, which among other things can help you to:
@@ -79,14 +79,14 @@ structure.
 
 ## Creating a subgroup
 
->**Notes:**
-- You need to be an Owner of a group in order to be able to create
-  a subgroup. For more information check the [permissions table][permissions].
-- For a list of words that are not allowed to be used as group names see the
-  [reserved names][reserved].
-- Users can always create subgroups if they are explicitly added as an Owner to
-  a parent group even if group creation is disabled by an administrator in their
-  settings.
+> **Notes:**
+> - You need to be an Owner of a group in order to be able to create
+>   a subgroup. For more information check the [permissions table][permissions].
+> - For a list of words that are not allowed to be used as group names see the
+>   [reserved names][reserved].
+> - Users can always create subgroups if they are explicitly added as an Owner to
+>   a parent group even if group creation is disabled by an administrator in their
+>   settings.
 
 To create a subgroup:
 

doc/user/markdown.md

@@ -66,15 +66,15 @@ GFM honors the markdown specification in how [paragraphs and line breaks are han
 A paragraph is simply one or more consecutive lines of text, separated by one or more blank lines.
 Line-breaks, or soft returns, are rendered if you end a line with two or more spaces:
 
-[//]: # (Do *NOT* remove the two ending whitespaces in the following line.)
-[//]: # (They are needed for the Markdown text to render correctly.)
+<!-- (Do *NOT* remove the two ending whitespaces in the following line.) -->
+<!-- (They are needed for the Markdown text to render correctly.) -->
     Roses are red [followed by two or more spaces]  
     Violets are blue
 
     Sugar is sweet
 
-[//]: # (Do *NOT* remove the two ending whitespaces in the following line.)
-[//]: # (They are needed for the Markdown text to render correctly.)
+<!-- (Do *NOT* remove the two ending whitespaces in the following line.) -->
+<!-- (They are needed for the Markdown text to render correctly.) -->
 Roses are red  
 Violets are blue
 
@@ -472,7 +472,7 @@ Become:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15107) in
 GitLab 10.3.
-
+>
 > If this is not rendered correctly, see
 https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#mermaid
 

doc/user/profile/account/two_factor_authentication.md

@@ -59,8 +59,8 @@ of recovery codes.
 ### Enable 2FA via U2F device
 
 > **Notes:**
-- GitLab officially only supports [Yubikey] U2F devices.
-- Support for U2F devices was added in GitLab 8.8.
+> - GitLab officially only supports [Yubikey] U2F devices.
+> - Support for U2F devices was added in GitLab 8.8.
 
 **In GitLab:**
 
@@ -145,7 +145,7 @@ codes. If you saved these codes, you can use one of them to sign in.
 To use a recovery code, enter your username/email and password on the GitLab
 sign-in page. When prompted for a two-factor code, enter the recovery code.
 
->**Note:**
+> **Note:**
 Once you use a recovery code, you cannot re-use it. You can still use the other
 recovery codes you saved.
 
@@ -187,7 +187,7 @@ a new set of recovery codes with SSH.
    When prompted for a two-factor code, enter one of the recovery codes obtained
    from the command-line output.
 
->**Note:**
+> **Note:**
 After signing in, visit your **Profile settings > Account**  immediately to set
 up two-factor authentication with a new device.
 

doc/user/project/bulk_editing.md

 # Bulk editing issues and merge requests
 
->
-**Notes:**
-- A permission level of `Reporter` or higher is required in order to manage
-issues.
-- A permission level of `Developer` or higher is required in order to manage
-merge requests.
+> **Notes:**
+> - A permission level of `Reporter` or higher is required in order to manage
+>   issues.
+> - A permission level of `Developer` or higher is required in order to manage
+>   merge requests.
 
 Attributes can be updated simultaneously across multiple issues or merge requests
 by using the bulk editing feature.

doc/user/project/container_registry.md

 # GitLab Container Registry
 
->**Notes:**
+> **Notes:**
 > [Introduced][ce-4040] in GitLab 8.8.
-- Docker Registry manifest `v1` support was added in GitLab 8.9 to support Docker
-  versions earlier than 1.10.
-- This document is about the user guide. To learn how to enable GitLab Container
-  Registry across your GitLab instance, visit the
-  [administrator documentation](../../administration/container_registry.md).
-- Starting from GitLab 8.12, if you have 2FA enabled in your account, you need
-  to pass a [personal access token][pat] instead of your password in order to
-  login to GitLab's Container Registry.
-- Multiple level image names support was added in GitLab 9.1
+> - Docker Registry manifest `v1` support was added in GitLab 8.9 to support Docker
+>   versions earlier than 1.10.
+> - This document is about the user guide. To learn how to enable GitLab Container
+>   Registry across your GitLab instance, visit the
+>   [administrator documentation](../../administration/container_registry.md).
+> - Starting from GitLab 8.12, if you have 2FA enabled in your account, you need
+>   to pass a [personal access token][pat] instead of your password in order to
+>   login to GitLab's Container Registry.
+> - Multiple level image names support was added in GitLab 9.1
 
 With the Docker Container Registry integrated into GitLab, every project can
 have its own space to store its Docker images.
@@ -40,12 +40,12 @@ to enable it.
 
 ## Build and push images
 
->**Notes:**
-- Moving or renaming existing container registry repositories is not supported
-once you have pushed images because the images are signed, and the
-signature includes the repository name.
-- To move or rename a repository with a container registry you will have to
-delete all existing images.
+> **Notes:**
+> - Moving or renaming existing container registry repositories is not supported
+>   once you have pushed images because the images are signed, and the
+>   signature includes the repository name.
+> - To move or rename a repository with a container registry you will have to
+>   delete all existing images.
 
 
 If you visit the **Registry** link under your project's menu, you can see the

doc/user/project/cycle_analytics.md

@@ -72,7 +72,7 @@ Here's a little explanation of how this works behind the scenes:
    `<issue, merge request>` pair, the merge request has the [issue closing pattern]
    for the corresponding issue. All other issues and merge requests are **not**
    considered.
-1. Then the <issue, merge request> pairs are filtered out by last XX days (specified
+1. Then the `<issue, merge request>` pairs are filtered out by last XX days (specified
    by the UI - default is 90 days). So it prohibits these pairs from being considered.
 1. For the remaining `<issue, merge request>` pairs, we check the information that
    we need for the stages, like issue creation date, merge request merge time,

doc/user/project/integrations/bamboo.md

@@ -57,6 +57,6 @@ service in GitLab.
 If builds are not triggered, ensure you entered the right GitLab IP address in
 Bamboo under 'Trigger IP addresses'.
 
->**Note:**
-- Starting with GitLab 8.14.0, builds are triggered on push events.
+> **Note:**
+> - Starting with GitLab 8.14.0, builds are triggered on push events.
 

doc/user/project/integrations/jira.md

@@ -92,15 +92,15 @@ password as they will be needed when configuring GitLab in the next section.
 
 ### Configuring GitLab
 
->**Notes:**
-- The currently supported JIRA versions are `v6.x` and `v7.x.`. GitLab 7.8 or
-  higher is required.
-- GitLab 8.14 introduced a new way to integrate with JIRA which greatly simplified
-  the configuration options you have to enter. If you are using an older version,
-  [follow this documentation][jira-repo-old-docs].
-- In order to support Oracle's Access Manager, GitLab will send additional cookies
-  to enable Basic Auth. The cookie being added to each request is `OBBasicAuth` with
-  a value of `fromDialog`.
+> **Notes:**
+> - The currently supported JIRA versions are `v6.x` and `v7.x.`. GitLab 7.8 or
+>   higher is required.
+> - GitLab 8.14 introduced a new way to integrate with JIRA which greatly simplified
+>   the configuration options you have to enter. If you are using an older version,
+>   [follow this documentation][jira-repo-old-docs].
+> - In order to support Oracle's Access Manager, GitLab will send additional cookies
+>   to enable Basic Auth. The cookie being added to each request is `OBBasicAuth` with
+>   a value of `fromDialog`.
 
 To enable JIRA integration in a project, navigate to the
 [Integrations page](project_services.md#accessing-the-project-services), click
@@ -182,11 +182,11 @@ the same goal:
 
 where `PROJECT-1` is the issue ID of the JIRA project.
 
->**Note:**
-- Only commits and merges into the project's default branch (usually **master**) will
-  close an issue in Jira. You can change your projects default branch under
-  [project settings](img/jira_project_settings.png).
-- The JIRA issue will not be transitioned if it has a resolution.
+> **Notes:**
+> - Only commits and merges into the project's default branch (usually **master**) will
+>   close an issue in Jira. You can change your projects default branch under
+>   [project settings](img/jira_project_settings.png).
+> - The JIRA issue will not be transitioned if it has a resolution.
 
 ### JIRA issue closing example
 

doc/user/project/integrations/webhooks.md

 # Webhooks
 
->**Note:**
-Starting from GitLab 8.5:
-- the `repository` key is deprecated in favor of the `project` key
-- the `project.ssh_url` key is deprecated in favor of the `project.git_ssh_url` key
-- the `project.http_url` key is deprecated in favor of the `project.git_http_url` key
-
->**Note:**
-Starting from GitLab 11.1, the logs of web hooks are automatically removed after
-one month.
-
->**Note**
-Starting from GitLab 11.2:
-- The `description` field for issues, merge requests, comments, and wiki pages
-  is rewritten so that simple Markdown image references (like
-  `![](/uploads/...)`) have their target URL changed to an absolute URL. See
-  [image URL rewriting](#image-url-rewriting) for more details.
+> **Note:**
+> Starting from GitLab 8.5:
+> - the `repository` key is deprecated in favor of the `project` key
+> - the `project.ssh_url` key is deprecated in favor of the `project.git_ssh_url` key
+> - the `project.http_url` key is deprecated in favor of the `project.git_http_url` key
+>
+> **Note:**
+> Starting from GitLab 11.1, the logs of web hooks are automatically removed after
+> one month.
+>
+> **Note:**
+> Starting from GitLab 11.2:
+> - The `description` field for issues, merge requests, comments, and wiki pages
+>   is rewritten so that simple Markdown image references (like
+>   `![](/uploads/...)`) have their target URL changed to an absolute URL. See
+>   [image URL rewriting](#image-url-rewriting) for more details.
 
 Project webhooks allow you to trigger a URL if for example new code is pushed or
 a new issue is created. You can configure webhooks to listen for specific events
@@ -320,7 +320,7 @@ X-Gitlab-Event: Issue Hook
 }
 ```
 
-**Note**: `assignee` and `assignee_id` keys are deprecated and now show the first assignee only.
+> **Note**: `assignee` and `assignee_id` keys are deprecated and now show the first assignee only.
 
 ### Comment events
 
@@ -619,7 +619,7 @@ X-Gitlab-Event: Note Hook
 }
 ```
 
-**Note**: `assignee_id` field is deprecated and now shows the first assignee only.
+> **Note**: `assignee_id` field is deprecated and now shows the first assignee only.
 
 #### Comment on code snippet
 
@@ -1174,7 +1174,7 @@ On this page, you can see data that GitLab sends (request headers and body) and
 
 From this page, you can repeat delivery with the same data by clicking `Resend Request` button.
 
->**Note:** If URL or secret token of the webhook were updated, data will be delivered to the new address.
+> **Note:** If URL or secret token of the webhook were updated, data will be delivered to the new address.
 
 ### Receiving duplicate or multiple web hook requests triggered by one event
 

doc/user/project/issue_board.md

@@ -354,7 +354,7 @@ To remove an assignee list, just as with a label list, click the trash icon.
 When dragging issues between lists, different behavior occurs depending on the source list and the target list.
 
 |                            | To Open            | To Closed    | To label `B` list            | To assignee `Bob` list                |
-| --- | --- | --- | --- | ---  |
+|----------------------------|--------------------|--------------|------------------------------|---------------------------------------|
 | From Open                  | -                  | Issue closed | `B` added                    | `Bob` assigned                        |
 | From Closed                | Issue reopened     | -            | Issue reopened<br/>`B` added | Issue reopened<br/>`Bob` assigned     |
 | From label `A` list        | `A` removed        | Issue closed | `A` removed<br/>`B` added    | `Bob` assigned                        |
@@ -364,8 +364,8 @@ When dragging issues between lists, different behavior occurs depending on the s
 
 Different issue board features are available in different [GitLab tiers](https://about.gitlab.com/pricing/), as shown in the following table:
 
-| Tier | Number of Project Issue Boards | Number of Group Issue Boards | Configurable Issue Boards | Assignee Lists
-| --- | --- | --- | --- | --- | --- |
+| Tier     | Number of Project Issue Boards | Number of Group Issue Boards | Configurable Issue Boards | Assignee Lists |
+|----------|--------------------------------|------------------------------|---------------------------|----------------|
 | Core     | 1                              | 1                            | No                        | No             |
 | Starter  | Multiple                       | 1                            | Yes                       | No             |
 | Premium  | Multiple                       | Multiple                     | Yes                       | Yes            |

doc/user/project/koding.md

 # Koding integration
 
->**Notes:**
-- **As of GitLab 10.0, the Koding integration is deprecated and will be removed
-  in a future version.**
-- [Introduced][ce-5909] in GitLab 8.11.
+> **Notes:**
+> - **As of GitLab 10.0, the Koding integration is deprecated and will be removed
+>   in a future version.**
+> - [Introduced][ce-5909] in GitLab 8.11.
 
 This document will guide you through using Koding integration on GitLab in
 detail. For configuring and installing please follow the

doc/user/project/merge_requests/versions.md

 # Merge requests versions
 
->**Notes:**
-- [Introduced][ce-5467] in GitLab 8.12.
-- Comments are disabled while viewing outdated merge versions or comparing to
-  versions other than base.
-- Merge request versions are based on push not on commit. So, if you pushed 5
-  commits in a single push, it will be a single option in the dropdown. If you
-  pushed 5 times, that will count for 5 options.
+> **Notes:**
+> - [Introduced][ce-5467] in GitLab 8.12.
+> - Comments are disabled while viewing outdated merge versions or comparing to
+>   versions other than base.
+> - Merge request versions are based on push not on commit. So, if you pushed 5
+>   commits in a single push, it will be a single option in the dropdown. If you
+>   pushed 5 times, that will count for 5 options.
 
 Every time you push to a branch that is tied to a merge request, a new version
 of merge request diff is created. When you visit a merge request that contains

doc/user/project/new_ci_build_permissions_model.md

@@ -205,16 +205,16 @@ With the update permission model we also extended the support for accessing
 Container Registries for private projects.
 
 > **Notes:**
-- GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
-  for permissions. This makes the `image:` directive to not work with private
-  projects automatically and it needs to be configured manually on Runner's host
-  with a predefined account (for example administrator's personal account with
-  access token created explicitly for this purpose). This issue is resolved with
-  latest changes in GitLab Runner 1.8 which receives GitLab credentials with
-  build data.
-- Starting from GitLab 8.12, if you have [2FA] enabled in your account, you need
-  to pass a [personal access token][pat] instead of your password in order to
-  login to GitLab's Container Registry.
+> - GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
+>   for permissions. This makes the `image:` directive to not work with private
+>   projects automatically and it needs to be configured manually on Runner's host
+>   with a predefined account (for example administrator's personal account with
+>   access token created explicitly for this purpose). This issue is resolved with
+>   latest changes in GitLab Runner 1.8 which receives GitLab credentials with
+>   build data.
+> - Starting from GitLab 8.12, if you have [2FA] enabled in your account, you need
+>   to pass a [personal access token][pat] instead of your password in order to
+>   login to GitLab's Container Registry.
 
 Your jobs can access all container images that you would normally have access
 to. The only implication is that you can push to the Container Registry of the

doc/user/project/pages/index.md

@@ -12,16 +12,16 @@ With GitLab Pages it's easy to publish your project website. GitLab Pages is a h
 to get you started quickly, or,
 alternatively, start from an existing project as follows:
 
-- 1. [Fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project) an [example project](https://gitlab.com/pages):
-by forking a project, you create a copy of the codebase you're forking from to start from a template instead of starting from scratch.
-- 2. Change a file to trigger a GitLab CI/CD pipeline: GitLab CI/CD will build and deploy your site to GitLab Pages.
-- 3. Visit your project's **Settings > Pages** to see your **website link**, and click on it. Bam! Your website is live! :)
+1. [Fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project) an [example project](https://gitlab.com/pages):
+   by forking a project, you create a copy of the codebase you're forking from to start from a template instead of starting from scratch.
+2. Change a file to trigger a GitLab CI/CD pipeline: GitLab CI/CD will build and deploy your site to GitLab Pages.
+3. Visit your project's **Settings > Pages** to see your **website link**, and click on it. Bam! Your website is live! :)
 
-_Further steps (optional):_
+    _Further steps (optional):_
 
-- 4. Remove the [fork relationship](getting_started_part_two.md#fork-a-project-to-get-started-from)
-(_You don't need the relationship unless you intent to contribute back to the example project you forked from_).
-- 5. Make it a [user/group website](getting_started_part_one.md#user-and-group-websites)
+4. Remove the [fork relationship](getting_started_part_two.md#fork-a-project-to-get-started-from)
+   (_You don't need the relationship unless you intent to contribute back to the example project you forked from_).
+5. Make it a [user/group website](getting_started_part_one.md#user-and-group-websites)
 
 **Watch a video with the steps above: https://www.youtube.com/watch?v=TWqh9MtT4Bg**
 

doc/user/project/pipelines/job_artifacts.md

 # Introduction to job artifacts
 
->**Notes:**
->- Since GitLab 8.2 and GitLab Runner 0.7.0, job artifacts that are created by
-   GitLab Runner are uploaded to GitLab and are downloadable as a single archive
-   (`tar.gz`) using the GitLab UI.
->- Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
-   changed to `ZIP`, and it is now possible to browse its contents, with the added
-   ability of downloading the files separately.
->- Starting with GitLab 8.17, builds are renamed to jobs.
->- The artifacts browser will be available only for new artifacts that are sent
-   to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
-   browse old artifacts already uploaded to GitLab.
+> **Notes:**
+> - Since GitLab 8.2 and GitLab Runner 0.7.0, job artifacts that are created by
+>   GitLab Runner are uploaded to GitLab and are downloadable as a single archive
+>   (`tar.gz`) using the GitLab UI.
+> - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
+>   changed to `ZIP`, and it is now possible to browse its contents, with the added
+>   ability of downloading the files separately.
+> - Starting with GitLab 8.17, builds are renamed to jobs.
+> - The artifacts browser will be available only for new artifacts that are sent
+>   to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
+>   browse old artifacts already uploaded to GitLab.
 >- This is the user documentation. For the administration guide see
-   [administration/job_artifacts](../../../administration/job_artifacts.md).
+>   [administration/job_artifacts](../../../administration/job_artifacts.md).
 
 Artifacts is a list of files and directories which are attached to a job
 after it completes successfully. This feature is enabled by default in all
@@ -46,14 +46,14 @@ For more examples on artifacts, follow the [artifacts reference in
 
 ## Browsing artifacts
 
->**Note:**
-With GitLab 9.2, PDFs, images, videos and other formats can be previewed
-directly in the job artifacts browser without the need to download them.
-
->**Note:**
-With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
-directly in a new tab without the need to download them when
-[GitLab Pages](../../../administration/pages/index.md) is enabled
+> **Note:**
+> With GitLab 9.2, PDFs, images, videos and other formats can be previewed
+> directly in the job artifacts browser without the need to download them.
+>
+> **Note:**
+> With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
+> directly in a new tab without the need to download them when
+> [GitLab Pages](../../../administration/pages/index.md) is enabled
 
 After a job finishes, if you visit the job's specific page, there are three
 buttons. You can download the artifacts archive or browse its contents, whereas

doc/user/project/pipelines/schedules.md

 # Pipeline Schedules
 
 > **Notes**:
-- This feature was introduced in 9.1 as [Trigger Schedule][ce-10533].
-- In 9.2, the feature was [renamed to Pipeline Schedule][ce-10853].
-- Cron notation is parsed by [Rufus-Scheduler](https://github.com/jmettraux/rufus-scheduler).
+> - This feature was introduced in 9.1 as [Trigger Schedule][ce-10533].
+> - In 9.2, the feature was [renamed to Pipeline Schedule][ce-10853].
+> - Cron notation is parsed by [Rufus-Scheduler](https://github.com/jmettraux/rufus-scheduler).
 
 Pipeline schedules can be used to run a pipeline at specific intervals, for example every
 month on the 22nd for a certain branch.
@@ -19,7 +19,7 @@ In order to schedule a pipeline:
 
 ![New Schedule Form](img/pipeline_schedules_new_form.png)
 
->**Attention:**
+> **Attention:**
 The pipelines won't be executed precisely, because schedules are handled by
 Sidekiq, which runs according to its interval.
 See [advanced admin configuration](#advanced-admin-configuration) for more
@@ -83,7 +83,7 @@ The next time a pipeline is scheduled, your credentials will be used.
 
 ![Schedules list](img/pipeline_schedules_ownership.png)
 
->**Note:**
+> **Note:**
 When the owner of the schedule doesn't have the ability to create pipelines
 anymore, due to e.g., being blocked or removed from the project, or lacking
 the permission to run on protected branches or tags. When this happened, the

doc/user/project/protected_branches.md

@@ -76,7 +76,7 @@ You can specify a wildcard protected branch, which will protect all branches
 matching the wildcard. For example:
 
 | Wildcard Protected Branch | Matching Branches                                      |
-|---------------------------+--------------------------------------------------------|
+|---------------------------|--------------------------------------------------------|
 | `*-stable`                | `production-stable`, `staging-stable`                  |
 | `production/*`            | `production/app-server`, `production/load-balancer`    |
 | `*gitlab*`                | `gitlab`, `gitlab/staging`, `master/gitlab/production` |

doc/user/project/protected_tags.md

@@ -37,7 +37,7 @@ You can specify a wildcard protected tag, which will protect all tags
 matching the wildcard. For example:
 
 | Wildcard Protected Tag | Matching Tags                 |
-|------------------------+-------------------------------|
+|------------------------|-------------------------------|
 | `v*`                   | `v1.0.0`, `version-9.1`       |
 | `*-deploy`             | `march-deploy`, `1.0-deploy`  |
 | `*gitlab*`             | `gitlab`, `gitlab/v1`         |