Resolve "CE documentation is not CommonMark compliant"

CONTRIBUTING.md

@@ -36,7 +36,7 @@ _This notice should stay as the first item in the CONTRIBUTING.md file._
   - [Release Scoping labels](#release-scoping-labels)
   - [Priority labels](#priority-labels)
   - [Severity labels](#severity-labels)
-    - [Severity impact guidance](#severity-impact-guidance)
+     - [Severity impact guidance](#severity-impact-guidance)
   - [Label for community contributors](#label-for-community-contributors)
 - [Implement design & UI elements](#implement-design--ui-elements)
 - [Issue tracker](#issue-tracker)

doc/administration/auth/ldap.md

@@ -382,29 +382,30 @@ the configuration option `lowercase_usernames`. By default, this configuration o
 1. Edit `/etc/gitlab/gitlab.rb`:
-  ```ruby
-  gitlab_rails['ldap_servers'] = YAML.load <<-EOS
-  main:
-    # snip...
-    lowercase_usernames: true
-  EOS
-  ```
-2. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+    ```ruby
+    gitlab_rails['ldap_servers'] = YAML.load <<-EOS
+    main:
+      # snip...
+      lowercase_usernames: true
+    EOS
+    ```
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 **Source configuration**
 1. Edit `config/gitlab.yaml`:
-  ```yaml
-  production:
-    ldap:
-      servers:
-        main:
-          # snip...
-          lowercase_usernames: true
-  ```
-2. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+    ```yaml
+    production:
+      ldap:
+        servers:
+          main:
+            # snip...
+            lowercase_usernames: true
+    ```
+
+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/README.md

@@ -37,7 +37,7 @@ Follow the steps below to configure an active/active setup:
 1. [Configure the database](database.md)
 1. [Configure Redis](redis.md)
-  1. [Configure Redis for GitLab source installations](redis_source.md)
+   1. [Configure Redis for GitLab source installations](redis_source.md)
 1. [Configure NFS](nfs.md)
 1. [Configure the GitLab application servers](gitlab.md)
 1. [Configure the load balancers](load_balancer.md)

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
@@ -383,9 +382,9 @@ multiple machines with the Sentinel daemon.
      [Download/install](https://about.gitlab.com/downloads-ee) the
      Omnibus GitLab Enterprise Edition package using **steps 1 and 2** from the
      GitLab downloads page.
-       - Make sure you select the correct Omnibus package, with the same version
-         the GitLab application is running.
-       - Do not complete any other steps on the download page.
+     - Make sure you select the correct Omnibus package, with the same version
+       the GitLab application is running.
+     - Do not complete any other steps on the download page.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents (if you are installing the
    Sentinels in the same node as the other Redis instances, some values might

doc/administration/index.md

@@ -135,15 +135,15 @@ created in snippets, wikis, and repos.
 - [Monitoring GitLab](monitoring/index.md):
   - [Monitoring uptime](../user/admin_area/monitoring/health_check.md): Check the server status using the health check endpoint.
-    - [IP whitelist](monitoring/ip_whitelist.md): Monitor endpoints that provide health check information when probed.
-    - [Monitoring GitHub imports](monitoring/github_imports.md): GitLab's GitHub Importer displays Prometheus metrics to monitor the health and progress of the importer.
+  - [IP whitelist](monitoring/ip_whitelist.md): Monitor endpoints that provide health check information when probed.
+  - [Monitoring GitHub imports](monitoring/github_imports.md): GitLab's GitHub Importer displays Prometheus metrics to monitor the health and progress of the importer.
 ### Performance Monitoring
 - [GitLab Performance Monitoring](monitoring/performance/index.md):
   - [Enable Performance Monitoring](monitoring/performance/gitlab_configuration.md): Enable GitLab Performance Monitoring.
   - [GitLab performance monitoring with InfluxDB](monitoring/performance/influxdb_configuration.md): Configure GitLab and InfluxDB for measuring performance metrics.
-    - [InfluxDB Schema](monitoring/performance/influxdb_schema.md): Measurements stored in InfluxDB.
+  - [InfluxDB Schema](monitoring/performance/influxdb_schema.md): Measurements stored in InfluxDB.
   - [GitLab performance monitoring with Prometheus](monitoring/prometheus/index.md): Configure GitLab and Prometheus for measuring performance metrics.
   - [GitLab performance monitoring with Grafana](monitoring/performance/grafana_configuration.md): Configure GitLab to visualize time series metrics through graphs and dashboards.
   - [Request Profiling](monitoring/performance/request_profiling.md): Get a detailed profile on slow requests.

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.
@@ -162,15 +162,15 @@ _The artifacts are stored by default in
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
-      ```bash
-      gitlab-rake gitlab:artifacts:migrate
-      ```
-      Currently this has to be executed manually and it will allow you to
-      migrate the existing artifacts to the object storage, but all new
-      artifacts will still be stored on the local disk. In the future
-      you will be given an option to define a default storage artifacts for all
-      new files.
+    ```bash
+    gitlab-rake gitlab:artifacts:migrate
+    ```
+    Currently this has to be executed manually and it will allow you to
+    migrate the existing artifacts to the object storage, but all new
+    artifacts will still be stored on the local disk. In the future
+    you will be given an option to define a default storage artifacts for all
+    new files.
 ---
@@ -198,15 +198,15 @@ _The artifacts are stored by default in
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
-      ```bash
-      sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
-      ```
-      Currently this has to be executed manually and it will allow you to
-      migrate the existing artifacts to the object storage, but all new
-      artifacts will still be stored on the local disk. In the future
-      you will be given an option to define a default storage artifacts for all
-      new files.
+    ```bash
+    sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
+    ```
+    Currently this has to be executed manually and it will allow you to
+    migrate the existing artifacts to the object storage, but all new
+    artifacts will still be stored on the local disk. In the future
+    you will be given an option to define a default storage artifacts for all
+    new files.
 ## Expiring artifacts
@@ -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/job_traces.md

@@ -67,24 +67,24 @@ To archive those legacy job traces, please follow the instruction below.
 1. Execute the following command
-      ```bash
-      gitlab-rake gitlab:traces:archive
-      ```
-      After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes)
-      for migrating job trace files from local storage to object storage. 
-      It could take time to complete the all migration jobs. You can check the progress by the following command
-      ```bash
-      sudo gitlab-rails console
-      ```
-      ```bash
-      [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace']
-      => 100
-      ```
-      If the count becomes zero, the archiving processes are done
+    ```bash
+    gitlab-rake gitlab:traces:archive
+    ```
+    After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes)
+    for migrating job trace files from local storage to object storage. 
+    It could take time to complete the all migration jobs. You can check the progress by the following command
+    ```bash
+    sudo gitlab-rails console
+    ```
+    ```bash
+    [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace']
+    => 100
+    ```
+    If the count becomes zero, the archiving processes are done
 ## How to migrate archived job traces to object storage
@@ -95,9 +95,9 @@ If job traces have already been archived into local storage, and you want to mig
 1. Ensure [Object storage integration for Job Artifacts](job_artifacts.md#object-storage-settings) is enabled
 1. Execute the following command
-      ```bash
-      gitlab-rake gitlab:traces:migrate
-      ```
+    ```bash
+    gitlab-rake gitlab:traces:migrate
+    ```
 ## How to remove job traces
@@ -185,15 +185,15 @@ with the legacy architecture.
 In some cases, having data stored on Redis could incur data loss:
 1. **Case 1: When all data in Redis are accidentally flushed**
-  - On going live traces could be recovered by re-sending traces (this is
-    supported by all versions of the GitLab Runner).
-  - Finished jobs which have not archived live traces will lose the last part
-    (~128KB) of trace data.
+   - On going live traces could be recovered by re-sending traces (this is
+     supported by all versions of the GitLab Runner).
+   - Finished jobs which have not archived live traces will lose the last part
+     (~128KB) of trace data.
 1. **Case 2: When Sidekiq workers fail to archive (e.g., there was a bug that
    prevents archiving process, Sidekiq inconsistency, etc.)**
-  - Currently all trace data in Redis will be deleted after one week. If the
-    Sidekiq workers can't finish by the expiry date, the part of trace data will be lost.
+   - Currently all trace data in Redis will be deleted after one week. If the
+     Sidekiq workers can't finish by the expiry date, the part of trace data will be lost.
 Another issue that might arise is that it could consume all memory on the Redis
 instance. If the number of jobs is 1000, 128MB (128KB * 1000) is consumed.

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
@@ -251,9 +251,9 @@ Follow the steps below to configure verbose logging of GitLab Pages daemon.
    If you wish to make it log events with level `DEBUG` you must configure this in
    `/etc/gitlab/gitlab.rb`:
-     ```shell
-     gitlab_pages['log_verbose'] = true
-     ```
+    ```shell
+    gitlab_pages['log_verbose'] = true
+    ```
 1. [Reconfigure GitLab][reconfigure]
@@ -266,9 +266,9 @@ are stored.
    If you wish to store them in another location you must set it up in
    `/etc/gitlab/gitlab.rb`:
-     ```shell
-     gitlab_rails['pages_path'] = "/mnt/storage/pages"
-     ```
+    ```shell
+    gitlab_rails['pages_path'] = "/mnt/storage/pages"
+    ```
 1. [Reconfigure GitLab][reconfigure]
@@ -279,19 +279,19 @@ Omnibus GitLab 11.1.
 1. By default the listener is configured to listen for requests on `localhost:8090`.
-   If you wish to disable it you must configure this in
-   `/etc/gitlab/gitlab.rb`:
-     ```shell
-     gitlab_pages['listen_proxy'] = nil
-     ```
-   If you wish to make it listen on a different port you must configure this also in
-   `/etc/gitlab/gitlab.rb`:
-     ```shell
-     gitlab_pages['listen_proxy'] = "localhost:10080"
-     ```
+    If you wish to disable it you must configure this in
+    `/etc/gitlab/gitlab.rb`:
+    ```shell
+    gitlab_pages['listen_proxy'] = nil
+    ```
+    If you wish to make it listen on a different port you must configure this also in
+    `/etc/gitlab/gitlab.rb`:
+    ```shell
+    gitlab_pages['listen_proxy'] = "localhost:10080"
+    ```
 1. [Reconfigure GitLab][reconfigure]

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.
@@ -111,24 +111,24 @@ The Pages daemon doesn't listen to the outside world.
 1. Go to the GitLab installation directory:
-     ```bash
-     cd /home/git/gitlab
-     ```
+    ```bash
+    cd /home/git/gitlab
+    ```
 1. Edit `gitlab.yml` and under the `pages` setting, set `enabled` to `true` and
    the `host` to the FQDN under which GitLab Pages will be served:
-     ```yaml
-     ## GitLab Pages
-     pages:
-       enabled: true
-       # The location where pages are stored (default: shared/pages).
-       # path: shared/pages
-       host: example.io
-       port: 80
-       https: false
-     ```
+    ```yaml
+    ## GitLab Pages
+    pages:
+      enabled: true
+      # The location where pages are stored (default: shared/pages).
+      # path: shared/pages
+      host: example.io
+      port: 80
+      https: false
+    ```
 1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
    order to enable the pages daemon. In `gitlab_pages_options` the
@@ -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.
@@ -174,17 +174,17 @@ outside world.
 1. In `gitlab.yml`, set the port to `443` and https to `true`:
-     ```bash
-     ## GitLab Pages
-     pages:
-       enabled: true
-       # The location where pages are stored (default: shared/pages).
-       # path: shared/pages
-
-       host: example.io
-       port: 443
-       https: true
-     ```
+    ```bash
+    ## GitLab Pages
+    pages:
+      enabled: true
+      # The location where pages are stored (default: shared/pages).
+      # path: shared/pages
+
+      host: example.io
+      port: 443
+      https: true
+    ```
 1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
    order to enable the pages daemon. In `gitlab_pages_options` the
@@ -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
@@ -243,18 +243,18 @@ world. Custom domains are supported, but no TLS.
    `external_http` to the secondary IP on which the pages daemon will listen
    for connections:
-     ```yaml
-     pages:
-       enabled: true
-       # The location where pages are stored (default: shared/pages).
-       # path: shared/pages
-       host: example.io
-       port: 80
-       https: false
-       external_http: 192.0.2.2:80
-     ```
+    ```yaml
+    pages:
+      enabled: true
+      # The location where pages are stored (default: shared/pages).
+      # path: shared/pages
+      host: example.io
+      port: 80
+      https: false
+      external_http: 192.0.2.2:80
+    ```
 1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
    order to enable the pages daemon. In `gitlab_pages_options` the
@@ -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
@@ -309,20 +309,20 @@ world. Custom domains and TLS are supported.
    `external_http` and `external_https` to the secondary IP on which the pages
    daemon will listen for connections:
-     ```yaml
-     ## GitLab Pages
-     pages:
-       enabled: true
-       # The location where pages are stored (default: shared/pages).
-       # path: shared/pages
-       host: example.io
-       port: 443
-       https: true
-       external_http: 192.0.2.2:80
-       external_https: 192.0.2.2:443
-     ```
+    ```yaml
+    ## GitLab Pages
+    pages:
+      enabled: true
+      # The location where pages are stored (default: shared/pages).
+      # path: shared/pages
+      host: example.io
+      port: 443
+      https: true
+      external_http: 192.0.2.2:80
+      external_https: 192.0.2.2:443
+    ```
 1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
    order to enable the pages daemon. In `gitlab_pages_options` the
@@ -358,9 +358,9 @@ are stored.
    If you wish to store them in another location you must set it up in
    `/etc/gitlab/gitlab.rb`:
-     ```ruby
-     gitlab_rails['pages_path'] = "/mnt/storage/pages"
-     ```
+    ```ruby
+    gitlab_rails['pages_path'] = "/mnt/storage/pages"
+    ```
 1. [Reconfigure GitLab][reconfigure]
@@ -400,12 +400,12 @@ are stored.
    If you wish to store them in another location you must set it up in
    `gitlab.yml` under the `pages` section:
-     ```yaml
-     pages:
-       enabled: true
-       # The location where pages are stored (default: shared/pages).
-       path: /mnt/storage/pages
-     ```
+    ```yaml
+    pages:
+      enabled: true
+      # The location where pages are stored (default: shared/pages).
+      path: /mnt/storage/pages
+    ```
 1. [Restart GitLab][restart]

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,28 +120,28 @@ 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**.
-
-      ```bash
-      # gitlab-rake gitlab:uploads:migrate[uploader_class, model_class, mount_point]
-	  
-	  # Avatars
-	  gitlab-rake "gitlab:uploads:migrate[AvatarUploader, Project, :avatar]"
-	  gitlab-rake "gitlab:uploads:migrate[AvatarUploader, Group, :avatar]"
-	  gitlab-rake "gitlab:uploads:migrate[AvatarUploader, User, :avatar]"
-
-      # Attachments
-	  gitlab-rake "gitlab:uploads:migrate[AttachmentUploader, Note, :attachment]"
-	  gitlab-rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :logo]"
-	  gitlab-rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :header_logo]"
-
-      # Markdown
-	  gitlab-rake "gitlab:uploads:migrate[FileUploader, Project]"
-	  gitlab-rake "gitlab:uploads:migrate[PersonalFileUploader, Snippet]"
-	  gitlab-rake "gitlab:uploads:migrate[NamespaceFileUploader, Snippet]"
-	  gitlab-rake "gitlab:uploads:migrate[FileUploader, MergeRequest]"
-      ```
+    > **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]
+ 	
+    # Avatars
+    gitlab-rake "gitlab:uploads:migrate[AvatarUploader, Project, :avatar]"
+    gitlab-rake "gitlab:uploads:migrate[AvatarUploader, Group, :avatar]"
+    gitlab-rake "gitlab:uploads:migrate[AvatarUploader, User, :avatar]"
+ 
+    # Attachments
+    gitlab-rake "gitlab:uploads:migrate[AttachmentUploader, Note, :attachment]"
+    gitlab-rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :logo]"
+    gitlab-rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :header_logo]"
+ 
+    # Markdown
+    gitlab-rake "gitlab:uploads:migrate[FileUploader, Project]"
+    gitlab-rake "gitlab:uploads:migrate[PersonalFileUploader, Snippet]"
+    gitlab-rake "gitlab:uploads:migrate[NamespaceFileUploader, Snippet]"
+    gitlab-rake "gitlab:uploads:migrate[FileUploader, MergeRequest]"
+    ```
 ---
@@ -167,32 +168,30 @@ _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.
-
-      ```bash
-      # sudo -u git -H bundle exec rake gitlab:uploads:migrate
-	  
-	  # Avatars
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AvatarUploader, Project, :avatar]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AvatarUploader, Group, :avatar]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AvatarUploader, User, :avatar]"
-
-      # Attachments
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AttachmentUploader, Note, :attachment]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :logo]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :header_logo]"
-
-      # Markdown
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, Project]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[PersonalFileUploader, Snippet]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[NamespaceFileUploader, Snippet]"
-	  sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, MergeRequest]"
-	  
-      ```
+    > **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
+   
+    # Avatars
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AvatarUploader, Project, :avatar]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AvatarUploader, Group, :avatar]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AvatarUploader, User, :avatar]"
+ 
+    # Attachments
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AttachmentUploader, Note, :attachment]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :logo]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[AttachmentUploader, Appearance, :header_logo]"
+ 
+    # Markdown
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, Project]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[PersonalFileUploader, Snippet]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[NamespaceFileUploader, Snippet]"
+    sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, MergeRequest]"
+   
+    ```
 [reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab"
 [restart gitlab]: restart_gitlab.md#installations-from-source "How to restart GitLab"