Merge branch 'docs/fix-unordered-list-style' into 'master'

Resolve Markdown unordered lists not conforming to styleguide

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

7 files changed, 37 insertions, 38 deletions

diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md
index 833c1f367dd..987a0b9f350 100644
--- a/doc/administration/high_availability/redis.md
+++ b/doc/administration/high_availability/redis.md
@@ -545,10 +545,10 @@ discussed in [Redis setup overview](#redis-setup-overview) and
 
 Here is a list and description of each **machine** and the assigned **IP**:
 
-* `10.0.0.1`: Redis Master + Sentinel 1
-* `10.0.0.2`: Redis Slave 1 + Sentinel 2
-* `10.0.0.3`: Redis Slave 2 + Sentinel 3
-* `10.0.0.4`: GitLab application
+- `10.0.0.1`: Redis Master + Sentinel 1
+- `10.0.0.2`: Redis Slave 1 + Sentinel 2
+- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
 by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master**
diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md
index 2101d36d2b6..14e2784c419 100644
--- a/doc/administration/high_availability/redis_source.md
+++ b/doc/administration/high_availability/redis_source.md
@@ -214,10 +214,10 @@ For this example, **Sentinel 1** will be configured in the same machine as the
 
 Here is a list and description of each **machine** and the assigned **IP**:
 
-* `10.0.0.1`: Redis Master + Sentinel 1
-* `10.0.0.2`: Redis Slave 1 + Sentinel 2
-* `10.0.0.3`: Redis Slave 2 + Sentinel 3
-* `10.0.0.4`: GitLab application
+- `10.0.0.1`: Redis Master + Sentinel 1
+- `10.0.0.2`: Redis Slave 1 + Sentinel 2
+- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
 by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master**
diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md
index bb621b788f1..058346df56d 100644
--- a/doc/administration/housekeeping.md
+++ b/doc/administration/housekeeping.md
@@ -17,19 +17,18 @@ The housekeeping function will run a `repack` or `gc` depending on the
 
 For example in the following scenario a `git repack -d` will be executed:
 
-+ Project: pushes since gc counter (`pushes_since_gc`) = `10`
-+ Git GC period = `200`
-+ Full repack period = `50`
+- Project: pushes since gc counter (`pushes_since_gc`) = `10`
+- Git GC period = `200`
+- Full repack period = `50`
 
 When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when
 the `pushes_since_gc` value is 200 a `git gc` will be run.
 
-+ `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
-such as compressing filerevisions (to reduce disk space and increase performance)
-and removing unreachable objects which may have been created from prior invocations of
-`git add`. 
-
-+ `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
+- `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
+  such as compressing filerevisions (to reduce disk space and increase performance)
+  and removing unreachable objects which may have been created from prior invocations of
+  `git add`.
+- `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
 
 You can find this option under your **[Project] > Edit Project**.
 
@@ -39,4 +38,4 @@ You can find this option under your **[Project] > Edit Project**.
 
 [ce-2371]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2371 "Housekeeping merge request"
 [man-gc]: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc man page"
-[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
\ No newline at end of file
+[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index a04458f2019..40e03093743 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work
 can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md).
 In brief:
 
-* GitLab relies on the user to provide their own Kubernetes credentials, and to
+- GitLab relies on the user to provide their own Kubernetes credentials, and to
   appropriately label the pods they create when deploying.
-* When a user navigates to the terminal page for an environment, they are served
+- When a user navigates to the terminal page for an environment, they are served
   a JavaScript application that opens a WebSocket connection back to GitLab.
-* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
+- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
    rather than the Rails application server.
-* Workhorse queries Rails for connection details and user permissions; Rails
-  queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md)
-* Workhorse acts as a proxy server between the user's browser and the Kubernetes
+- Workhorse queries Rails for connection details and user permissions. Rails
+  queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md).
+- Workhorse acts as a proxy server between the user's browser and the Kubernetes
   API, passing WebSocket frames between the two.
-* Workhorse regularly polls Rails, terminating the WebSocket connection if the
+- Workhorse regularly polls Rails, terminating the WebSocket connection if the
   user no longer has permission to access the terminal, or if the connection
   details have changed.
 
@@ -53,10 +53,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) in
 front of GitLab, you may need to make some changes to your configuration. These
 guides document the necessary steps for a selection of popular reverse proxies:
 
-* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
-* [NGINX](https://www.nginx.com/blog/websocket-nginx/)
-* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
-* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
+- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
+- [NGINX](https://www.nginx.com/blog/websocket-nginx/)
+- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
+- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
 
 Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
 it's safe to enable support for these headers globally. If you'd rather had a
@@ -73,8 +73,8 @@ the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this will be the NGINX server bundled with
 Omnibus GitLab, in which case, you need to:
 
-* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
-* Ensure the whole block is uncommented, and then comment out or remove the
+- Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
+- Ensure the whole block is uncommented, and then comment out or remove the
   `Connection` and `Upgrade` lines.
 
 For your own load balancer, just reverse the configuration changes recommended
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 0ca1d77f1d0..d8f80965c21 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -52,9 +52,9 @@ and these checks will verify them against current files.
 
 Currently, integrity checks are supported for the following types of file:
 
-* CI artifacts (Available from version 10.7.0)
-* LFS objects (Available from version 10.6.0)
-* User uploads (Available from version 10.6.0)
+- CI artifacts (Available from version 10.7.0)
+- LFS objects (Available from version 10.6.0)
+- User uploads (Available from version 10.6.0)
 
 **Omnibus Installation**
 
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index 12238ba7b32..51e1518d73f 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -7,8 +7,8 @@
 Legacy Storage is the storage behavior prior to version 10.0. For historical
 reasons, GitLab replicated the same mapping structure from the projects URLs:
 
-* Project's repository: `#{namespace}/#{project_name}.git`
-* Project's wiki: `#{namespace}/#{project_name}.wiki.git`
+- Project's repository: `#{namespace}/#{project_name}.git`
+- Project's wiki: `#{namespace}/#{project_name}.wiki.git`
 
 This structure made it simple to migrate from existing solutions to GitLab and
 easy for Administrators to find where the repository is stored.
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 643c5b9fe80..bd702dcc9ec 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -211,5 +211,5 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause.
 
 # More information
 
-* [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
-* [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)
+- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
+- [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)