Add latest changes from gitlab-org/gitlab@master

4 files changed, 13 insertions, 12 deletions

diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md
index 0a20e94a778..019909e2e89 100644
--- a/doc/administration/operations/filesystem_benchmarking.md
+++ b/doc/administration/operations/filesystem_benchmarking.md
@@ -37,7 +37,7 @@ completes.
 The output will vary depending on what version of `fio` installed. The following
 is an example output from `fio` v2.2.10 on a networked solid-state drive (SSD):
 
-```
+```plaintext
 test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
     fio-2.2.10
     Starting 1 process
diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md
index d54ffacd281..a11bce9aa02 100644
--- a/doc/administration/operations/moving_repositories.md
+++ b/doc/administration/operations/moving_repositories.md
@@ -21,7 +21,7 @@ overhead and tar is almost always already installed on your system.
 However, it is not possible to resume an interrupted tar pipe:  if
 that happens then all data must be copied again.
 
-```
+```shell
 sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
   tar -C /mnt/gitlab/repositories -xf -'
 ```
@@ -34,7 +34,7 @@ You can also use a tar pipe to copy data to another server. If your
 `git` user has SSH access to the newserver as `git@newserver`, you
 can pipe the data through SSH.
 
-```
+```shell
 sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
   ssh git@newserver tar -C /mnt/gitlab/repositories -xf -'
 ```
@@ -50,7 +50,7 @@ with tar. In this scenario it is better to use rsync. This utility
 is either already installed on your system or easily installable
 via apt, yum etc.
 
-```
+```shell
 sudo -u git  sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
   /mnt/gitlab/repositories'
 ```
@@ -64,7 +64,7 @@ If you want to see progress, replace `-a` with `-av`.
 If the `git` user on your source system has SSH access to the target
 server you can send the repositories over the network with rsync.
 
-```
+```shell
 sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
   git@newserver:/mnt/gitlab/repositories'
 ```
@@ -99,7 +99,7 @@ First we create a new directory, owned by `git`, to hold transfer
 logs. We assume the directory is empty before we start the transfer
 procedure, and that we are the only ones writing files in it.
 
-```
+```shell
 # Omnibus
 sudo mkdir /var/opt/gitlab/transfer-logs
 sudo chown git:git /var/opt/gitlab/transfer-logs
@@ -110,7 +110,7 @@ sudo -u git -H mkdir /home/git/transfer-logs
 
 We seed the process with a list of the directories we want to copy.
 
-```
+```shell
 # Omnibus
 sudo -u git sh -c 'gitlab-rake gitlab:list_repos > /var/opt/gitlab/transfer-logs/all-repos-$(date +%s).txt'
 
@@ -124,7 +124,7 @@ the number of jobs done by GNU Parallel should converge to zero. If it
 does not, some repositories listed in `all-repos-1234.txt` may have been
 deleted/renamed before they could be copied.
 
-```
+```shell
 # Omnibus
 sudo -u git sh -c '
 cat /var/opt/gitlab/transfer-logs/* | sort | uniq -u |\
@@ -154,7 +154,7 @@ Then you might only want to sync repositories that were changed via GitLab
 _after_ that time. You can use the `SINCE` variable to tell `rake
 gitlab:list_repos` to only print repositories with recent activity.
 
-```
+```shell
 # Omnibus
 sudo gitlab-rake gitlab:list_repos SINCE='2015-10-1 12:00 UTC' |\
   sudo -u git \
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 2a9a4cff34e..b18c15e6b91 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -54,8 +54,9 @@ The SSH certificates being issued by that CA **MUST** have a "key id"
 corresponding to that user's username on GitLab, e.g. (some output
 omitted for brevity):
 
-```
+```shell
 $ ssh-add -L | grep cert | ssh-keygen -L -f -
+
 (stdin):1:
         Type: ssh-rsa-cert-v01@openssh.com user certificate
         Public key: RSA-CERT SHA256:[...]
diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md
index 969f1211643..a19617daaef 100644
--- a/doc/administration/operations/unicorn.md
+++ b/doc/administration/operations/unicorn.md
@@ -29,7 +29,7 @@ requests.
 This is what a Unicorn worker timeout looks like in `unicorn_stderr.log`. The
 master process has PID 56227 below.
 
-```
+```plaintext
 [2015-06-05T10:58:08.660325 #56227] ERROR -- : worker=10 PID:53009 timeout (61s > 60s), killing
 [2015-06-05T10:58:08.699360 #56227] ERROR -- : reaped #<Process::Status: pid 53009 SIGKILL (signal 9)> worker=10
 [2015-06-05T10:58:08.708141 #62538]  INFO -- : worker=10 spawned pid=62538
@@ -79,7 +79,7 @@ threshold is a random value between 200 and 250 MB.  The master process (PID
 117565) then reaps the worker process and spawns a new 'worker 4' with PID
 127549.
 
-```
+```plaintext
 [2015-06-05T12:07:41.828374 #125918]  WARN -- : #<Unicorn::HttpServer:0x00000002734770>: worker (pid: 125918) exceeds memory limit (256413696 bytes > 254802235 bytes)
 [2015-06-05T12:07:41.828472 #125918]  WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 125918) alive: 23 sec (trial 1)
 [2015-06-05T12:07:42.025916 #117565]  INFO -- : reaped #<Process::Status: pid 125918 exit 0> worker=4