Add language declarations to code blocks

Add yet more language declarations to code blocks.

doc/administration/auth/crowd.md

@@ -54,7 +54,7 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
 
    **Source:**
 
-   ```
+   ```yaml
       - { name: 'crowd',
           args: {
             crowd_server_url: 'CROWD_SERVER_URL',

doc/administration/auth/ldap.md

@@ -405,7 +405,7 @@ production:
 Tip: If you want to limit access to the nested members of an Active Directory
 group, you can use the following syntax:
 
-```text
+```plaintext
 (memberOf:1.2.840.113556.1.4.1941:=CN=My Group,DC=Example,DC=com)
 ```
 
@@ -423,13 +423,13 @@ The `user_filter` DN can contain special characters. For example:
 
 - A comma:
 
-  ```text
+  ```plaintext
   OU=GitLab, Inc,DC=gitlab,DC=com
   ```
 
 - Open and close brackets:
 
-  ```text
+  ```plaintext
   OU=Gitlab (Inc),DC=gitlab,DC=com
   ```
 
@@ -438,13 +438,13 @@ The `user_filter` DN can contain special characters. For example:
 
 - Escape commas with `\2C`. For example:
 
-  ```text
+  ```plaintext
   OU=GitLab\2C Inc,DC=gitlab,DC=com
   ```
 
 - Escape open and close brackets with `\28` and `\29`, respectively. For example:
 
-  ```text
+  ```plaintext
   OU=Gitlab \28Inc\29,DC=gitlab,DC=com
   ```
 
@@ -603,7 +603,7 @@ GitLab. Common combinations are `encryption: 'plain'` and `port: 389`, OR
 
 If GitLab cannot reach your LDAP endpoint, you will see a message like this:
 
-```
+```plaintext
 Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout".
 ```
 

doc/administration/geo/replication/database.md

@@ -495,7 +495,7 @@ work:
 
 1. On the **secondary** nodes, change `/etc/gitlab/gitlab.rb`:
 
-   ```
+   ```ruby
    geo_postgresql['fdw_external_user'] = 'gitlab_geo_fdw'
    ```
 

doc/administration/geo/replication/troubleshooting.md

@@ -46,7 +46,7 @@ sudo gitlab-rake gitlab:geo:check
 
 Example output:
 
-```text
+```plaintext
 Checking Geo ...
 
 GitLab Geo is available ... yes
@@ -79,7 +79,7 @@ sudo gitlab-rake geo:status
 
 Example output:
 
-```text
+```plaintext
 http://secondary.example.com/
 -----------------------------------------------------
                         GitLab Version: 11.10.4-ee
@@ -134,11 +134,11 @@ sudo gitlab-rake gitlab:geo:check
 It displays the current machine's node name and whether the matching database
 record is a **primary** or **secondary** node.
 
-```
+```plaintext
 This machine's Geo node name matches a database record ... yes, found a secondary node named "Shanghai"
 ```
 
-```
+```plaintext
 This machine's Geo node name matches a database record ... no
   Try fixing it:
   You could add or update a Geo node database record, setting the name to "https://example.com/".
@@ -157,7 +157,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Rails did not provide a password when connecting to the database
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... Exception: fe_sendauth: no password supplied
@@ -167,10 +167,10 @@ sudo gitlab-rake gitlab:geo:check
    ```
 
    - Ensure that you have the `gitlab_rails['db_password']` set to the plain text-password used when creating the hash for `postgresql['sql_user_password']`.
-
+```
 1. Rails is unable to connect to the database
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... Exception: FATAL:  no pg_hba.conf entry for host "1.1.1.1",  user "gitlab", database "gitlabhq_production", SSL on
@@ -186,7 +186,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Rails has supplied the incorrect password
 
-    ```text
+   ```plaintext
    Checking Geo ...
    GitLab Geo is available ... Exception: FATAL:  password authentication failed for user "gitlab"
    FATAL:  password authentication failed for user "gitlab"
@@ -200,7 +200,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Check returns not a secondary node
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... yes
@@ -217,7 +217,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Check returns Exception: PG::UndefinedTable: ERROR:  relation "geo_nodes" does not exist
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... no
@@ -483,7 +483,7 @@ when promoting a secondary to a primary node with strategies to resolve them.
 When [promoting a **secondary** node](../disaster_recovery/index.md#step-3-promoting-a-secondary-node),
 you might encounter the following error:
 
-```text
+```plaintext
 Running gitlab-rake geo:set_secondary_as_primary...
 
 rake aborted!
@@ -523,7 +523,7 @@ This section documents ways to fix potential Foreign Data Wrapper errors.
 When setting up Geo, you might see this warning in the `gitlab-rake
 gitlab:geo:check` output:
 
-```text
+```plaintext
 GitLab Geo tracking database Foreign Data Wrapper schema is up-to-date? ... foreign data wrapper is not configured
 ```
 
@@ -607,7 +607,7 @@ To check the configuration:
 1. Check that the foreign server mapping is correct via `\des+`. The
    results should look something like this:
 
-   ```
+   ```plaintext
    gitlabhq_geo_production=# \des+
    List of foreign servers
    -[ RECORD 1 ]--------+------------------------------------------------------------
@@ -643,7 +643,7 @@ To check the configuration:
 
 1. Check that the user mapping is configured properly via `\deu+`:
 
-   ```
+   ```plaintext
    gitlabhq_geo_production=# \deu+
                                                 List of user mappings
          Server      | User name  |                                  FDW Options
@@ -731,7 +731,7 @@ GitLab can error with a `Geo database has an outdated FDW remote schema` message
 
 For example:
 
-```text
+```plaintext
 Geo database has an outdated FDW remote schema. It contains 229 of 236 expected tables. Please refer to Geo Troubleshooting.
 ```
 

doc/administration/git_annex.md

@@ -43,13 +43,13 @@ configuration options required to enable it.
 
 For Debian-like systems (for example, Debian and Ubuntu) this can be achieved by running:
 
-```
+```shell
 sudo apt-get update && sudo apt-get install git-annex
 ```
 
 For RedHat-like systems (for example, CentOS and RHEL) this can be achieved by running:
 
-```
+```shell
 sudo yum install epel-release && sudo yum install git-annex
 ```
 
@@ -108,7 +108,7 @@ git annex sync --content         # sync the Git repo and large file to the GitLa
 
 The output should look like this:
 
-```
+```plaintext
 commit
 On branch master
 Your branch is ahead of 'origin/master' by 1 commit.
@@ -154,7 +154,7 @@ are turned into symbolic links that point to data in `.git/annex/objects/`.
 
 The `debian.iso` file in the example will contain the symbolic link:
 
-```
+```plaintext
 .git/annex/objects/ZW/1k/SHA256E-s82701--6384039733b5035b559efd5a2e25a493ab6e09aabfd5162cc03f6f0ec238429d.png/SHA256E-s82701--6384039733b5035b559efd5a2e25a493ab6e09aabfd5162cc03f6f0ec238429d.iso
 ```
 
@@ -216,14 +216,14 @@ and the files are pushed to the GitLab repository.
 If you get hit by this, you can run the following command inside the repository
 that the warning was raised:
 
-```
+```shell
 git config remote.origin.annex-ignore false
 ```
 
 Consecutive runs of `git annex sync --content` **should not** produce this
 warning and the output should look like this:
 
-```
+```plaintext
 commit  ok
 pull origin
 ok

doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md

@@ -57,7 +57,7 @@ Fire up a terminal, navigate to your Git repository and:
 
 1. Enable `git-lfs`:
 
-   ```
+   ```shell
    git lfs install
    git lfs track <files>
    git add .

doc/administration/logs.md

@@ -353,7 +353,7 @@ GitLab uses background jobs for processing tasks which can take a long
 time. All information about processing these jobs are written down to
 this file. For example:
 
-```
+```plaintext
 2014-06-10T07:55:20Z 2037 TID-tm504 ERROR: /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/1.9.1/gems/redis-3.0.7/lib/redis/client.rb:228:in `read'
 2014-06-10T18:18:26Z 14299 TID-55uqo INFO: Booting Sidekiq 3.0.0 with redis options {:url=>"redis://localhost:6379/0", :namespace=>"sidekiq"}
 ```

doc/administration/operations/ssh_certificates.md

@@ -40,7 +40,7 @@ it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/htm
 We assume that you already have SSH certificates set up, and have
 added the `TrustedUserCAKeys` of your CA to your `sshd_config`, e.g.:
 
-```
+```plaintext
 TrustedUserCAKeys /etc/security/mycompany_user_ca.pub
 ```
 
@@ -87,7 +87,7 @@ Then, in your `sshd_config` set up `AuthorizedPrincipalsCommand` for
 the `git` user. Hopefully you can use the default one shipped with
 GitLab:
 
-```
+```plaintext
 Match User git
     AuthorizedPrincipalsCommandUser root
     AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers
@@ -95,7 +95,7 @@ Match User git
 
 This command will emit output that looks something like:
 
-```
+```shell
 command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell username-{KEY_ID}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty {PRINCIPAL}
 ```
 
@@ -108,7 +108,7 @@ some principal that's guaranteed to be part of the key for all users
 who can log in to GitLab, or you must provide a list of principals,
 one of which is going to be present for the user, e.g.:
 
-```
+```plaintext
     [...]
     AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers windowsUsers
 ```

doc/administration/reply_by_email_postfix_setup.md

@@ -73,7 +73,7 @@ The instructions make the assumption that you will be using the email address `i
 
 1. Send the new `incoming` user a dummy email to test SMTP, by entering the following into the SMTP prompt:
 
-   ```
+   ```plaintext
    ehlo localhost
    mail from: root@localhost
    rcpt to: incoming@localhost
@@ -101,7 +101,7 @@ The instructions make the assumption that you will be using the email address `i
 
    You should see output like this:
 
-   ```
+   ```plaintext
    "/var/mail/incoming": 1 message 1 unread
    >U   1 root@localhost                           59/2842  Re: Some issue
    ```
@@ -147,7 +147,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
       You should see output like this:
 
-      ```
+      ```plaintext
       "/home/incoming/Maildir": 1 message 1 unread
       >U   1 root@localhost                           59/2842  Re: Some issue
       ```
@@ -253,7 +253,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    1. Send the `incoming` user a dummy email to test SMTP, by entering the following into the SMTP prompt:
 
-      ```
+      ```plaintext
       ehlo gitlab.example.com
       mail from: root@gitlab.example.com
       rcpt to: incoming@gitlab.example.com
@@ -277,7 +277,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
       You should see output like this:
 
-      ```
+      ```plaintext
       "/home/incoming/Maildir": 1 message 1 unread
       >U   1 root@gitlab.example.com                           59/2842  Re: Some issue
       ```
@@ -313,7 +313,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
    1. Sign in as the `incoming` user to test IMAP, by entering the following into the IMAP prompt:
 
-      ```
+      ```plaintext
       a login incoming PASSWORD
       ```
 
@@ -321,7 +321,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
       You should see output like this:
 
-      ```
+      ```plaintext
       a OK LOGIN Ok.
       ```
 

doc/administration/repository_storage_paths.md

@@ -15,7 +15,7 @@ storage shards) to distribute the storage load between several mount points.
 
 Example: this is OK:
 
-```
+```plaintext
 default:
   path: /mnt/git-storage-1
 storage2:
@@ -24,7 +24,7 @@ storage2:
 
 This is not OK because it nests storage paths:
 
-```
+```plaintext
 default:
   path: /mnt/git-storage-1
 storage2: