Add codeblock language tags to ci docs

Add language tags to codeblocks that were missing
them, in /ci files and pages files.

doc/administration/pages/index.md

@@ -83,7 +83,7 @@ GitLab Pages expect to run on their own virtual host. In your DNS server/provide
 you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
 host that GitLab runs. For example, an entry would look like this:
 
-```
+```plaintext
 *.example.io. 1800 IN A    192.0.2.1
 *.example.io. 1800 IN AAAA 2001::1
 ```

doc/administration/pages/source.md

@@ -64,7 +64,7 @@ GitLab Pages expect to run on their own virtual host. In your DNS server/provide
 you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
 host that GitLab runs. For example, an entry would look like this:
 
-```
+```plaintext
 *.example.io. 1800 IN A 192.0.2.1
 ```
 
@@ -131,7 +131,7 @@ The Pages daemon doesn't listen to the outside world.
    order to enable the pages daemon. In `gitlab_pages_options` the
    `-pages-domain` must match the `host` setting that you set above.
 
-   ```
+   ```ini
    gitlab_pages_enabled=true
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090"
    ```
@@ -170,7 +170,7 @@ outside world.
 
 1. In `gitlab.yml`, set the port to `443` and https to `true`:
 
-   ```shell
+   ```yaml
    ## GitLab Pages
    pages:
      enabled: true
@@ -188,9 +188,9 @@ outside world.
    The `-root-cert` and `-root-key` settings are the wildcard TLS certificates
    of the `example.io` domain:
 
-   ```
+   ```ini
    gitlab_pages_enabled=true
-   gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
+   gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key"
    ```
 
 1. Copy the `gitlab-pages-ssl` NGINX configuration file:
@@ -256,7 +256,7 @@ world. Custom domains are supported, but no TLS.
    `-pages-domain` and `-listen-http` must match the `host` and `external_http`
    settings that you set above respectively:
 
-   ```
+   ```ini
    gitlab_pages_enabled=true
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80"
    ```
@@ -325,9 +325,9 @@ world. Custom domains and TLS are supported.
    The `-root-cert` and `-root-key` settings are the wildcard TLS certificates
    of the `example.io` domain:
 
-   ```
+   ```ini
    gitlab_pages_enabled=true
-   gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
+   gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key"
    ```
 
 1. Copy the `gitlab-pages-ssl` NGINX configuration file:

doc/ci/ci_cd_for_external_repos/github_integration.md

@@ -85,9 +85,9 @@ To manually enable GitLab CI/CD for your repository:
 
    The web hook URL should be set to the GitLab API to
    [trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
-   using the GitLab personal access token we just created.
+   using the GitLab personal access token we just created:
 
-   ```
+   ```plaintext
    https://gitlab.com/api/v4/projects/<NAMESPACE>%2F<PROJECT>/mirror/pull?private_token=<PERSONAL_ACCESS_TOKEN>
    ```
 

doc/ci/directed_acyclic_graph/index.md

@@ -23,7 +23,7 @@ requiring a single keyword to enable the feature for any job.
 
 Consider a monorepo as follows:
 
-```
+```plaintext
 ./service_a
 ./service_b
 ./service_c

doc/ci/examples/artifactory_and_gitlab/index.md

@@ -39,7 +39,7 @@ project:
 1. Create a new project by selecting **Import project from ➔ Repo by URL**
 1. Add the following URL:
 
-   ```
+   ```plaintext
    https://gitlab.com/gitlab-examples/maven/simple-maven-dep.git
    ```
 
@@ -164,7 +164,7 @@ The deployment occurs only if we're pushing or merging to `master` branch, so th
 Done! Now you have all the changes in the GitLab repo, and a pipeline has already been started for this commit. In the **Pipelines** tab you can see what's happening.
 If the deployment has been successful, the deploy job log will output:
 
-```
+```plaintext
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
@@ -188,7 +188,7 @@ We'll use again a Maven app that can be cloned from our example project:
 1. Create a new project by selecting **Import project from ➔ Repo by URL**
 1. Add the following URL:
 
-   ```
+   ```plaintext
    https://gitlab.com/gitlab-examples/maven/simple-maven-app.git
    ```
 

doc/ci/examples/deployment/README.md

@@ -18,7 +18,7 @@ To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
 
 Dpl can be installed on any machine with:
 
-```
+```shell
 gem install dpl
 ```
 
@@ -27,7 +27,7 @@ having to test it on a CI server.
 
 If you don't have Ruby installed you can do it on Debian-compatible Linux with:
 
-```
+```shell
 apt-get update
 apt-get install ruby-dev
 ```

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -163,7 +163,7 @@ sudo nano /etc/nginx/sites-available/default
 
 The configuration should be like this.
 
-```
+```nginx
 server {
     root /var/www/app/current/public;
     server_name example.com;

doc/ci/examples/php.md

@@ -179,7 +179,7 @@ user following [the upstream installation guide][phpenv-installation].
 
 Using phpenv also allows to easily configure the PHP environment with:
 
-```
+```shell
 phpenv config-add my_config.ini
 ```
 

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -115,7 +115,7 @@ mix ecto.create
 
 We expect to see this output at the end of the command:
 
-```shell
+```plaintext
 Generated hello_gitlab_ci app
 The database for HelloGitlabCi.Repo has been created
 ```
@@ -136,7 +136,7 @@ mix phoenix.server
 
 This will be the output to this command:
 
-```shell
+```plaintext
 [info] Running HelloGitlabCi.Endpoint with Cowboy using http://localhost:4000
 23 May 11:44:35 - info: compiling
 23 May 11:44:37 - info: compiled 6 files into 2 files, copied 3 in 9.8 sec
@@ -229,7 +229,7 @@ mix test
 
 Our expected result is this:
 
-```shell
+```plaintext
 ....
 
 Finished in 0.7 seconds
@@ -265,20 +265,20 @@ project.
   As we are focusing on testing (not deploying), you can use the [elixir:latest](https://hub.docker.com/_/elixir) docker image, which already has the
   dependencies for running Phoenix tests installed, such as Elixir and Erlang:
 
-  ```yml
+  ```yaml
   image: elixir:latest
   ```
 
 - We'll only use `postgres`, so we can delete the `mysql` and `redis` lines from the `services` section:
 
-  ```yml
+  ```yaml
   services:
     - postgres:latest
   ```
 
 - Now, we'll create a new section called `variables`, before the `before_script` section:
 
-  ```yml
+  ```yaml
   variables:
     POSTGRES_DB: hello_gitlab_ci_test
     POSTGRES_HOST: postgres
@@ -293,7 +293,7 @@ project.
 
 - In the `before_script` section, we'll add some commands to prepare everything for the test:
 
-  ```yml
+  ```yaml
   before_script:
     - mix local.rebar --force
     - mix local.hex --force
@@ -310,7 +310,7 @@ project.
 
 Let's take a look at the updated file after the changes:
 
-```yml
+```yaml
 image: elixir:latest
 
 services:
@@ -353,7 +353,7 @@ actual running build job.
 Click on build's ID to watch the entire process. If everything went as expected, we can wait for the
 **Build succeeded** at the end of the process! :)
 
-```
+```shell
 $ mix test
 ....
 

doc/ci/ssh_keys/README.md

@@ -114,11 +114,11 @@ SSH key.
 You can generate the SSH key from the machine that GitLab Runner is installed
 on, and use that key for all projects that are run on this machine.
 
-1. First, you need to login to the server that runs your jobs.
+1. First, log in to the server that runs your jobs.
 
-1. Then from the terminal login as the `gitlab-runner` user:
+1. Then, from the terminal, log in as the `gitlab-runner` user:
 
-   ```
+   ```shell
    sudo su - gitlab-runner
    ```
 
@@ -132,7 +132,7 @@ on, and use that key for all projects that are run on this machine.
    If you are accessing a private GitLab repository you need to add it as a
    [deploy key](../../ssh/README.md#deploy-keys).
 
-Once done, try to login to the remote server in order to accept the fingerprint:
+Once done, try to log in to the remote server in order to accept the fingerprint:
 
 ```shell
 ssh example.com

doc/ci/triggers/README.md

@@ -110,7 +110,7 @@ The action is irreversible.
 
 To trigger a job you need to send a `POST` request to GitLab's API endpoint:
 
-```
+```plaintext
 POST /projects/:id/trigger/pipeline
 ```
 
@@ -185,7 +185,7 @@ Now, whenever a new tag is pushed on project A, the job will run and the
 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):
 
-```
+```plaintext
 https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN
 ```
 
@@ -195,7 +195,7 @@ You can pass any number of arbitrary variables in the trigger API call and they
 will be available in GitLab CI so that they can be used in your `.gitlab-ci.yml`
 file. The parameter is of the form:
 
-```
+```plaintext
 variables[key]=value
 ```
 

doc/migrate_ci_to_ce/README.md

@@ -51,7 +51,7 @@ Otherwise it's pretty likely that you will encounter problems described in the [
 
 Make sure that the backup script on both servers can connect to the database.
 
-```
+```shell
 # On your CI server:
 # Omnibus
 sudo chown gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
@@ -64,7 +64,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:create RAILS_ENV=production
 
 Also check on your GitLab server.
 
-```
+```shell
 # On your GitLab server:
 # Omnibus
 sudo gitlab-backup create SKIP=repositories,uploads
@@ -89,7 +89,7 @@ MySQL and your GitLab server uses PostgreSQL you need to pass a special option
 during the 'Moving data' part. **If your CI server uses PostgreSQL and your
 GitLab server uses MySQL you cannot migrate your CI data to GitLab 8.0.**
 
-```
+```shell
 # On your CI server:
 # Omnibus
 sudo gitlab-ci-rake env:info
@@ -99,7 +99,7 @@ cd /home/gitlab_ci/gitlab-ci
 sudo -u gitlab_ci -H bundle exec rake env:info RAILS_ENV=production
 ```
 
-```
+```shell
 # On your GitLab server:
 # Omnibus
 sudo gitlab-rake gitlab:env:info
@@ -149,7 +149,7 @@ Now upgrade GitLab CI to version 8.0. If you are using Omnibus packages,
 
 Disable GitLab CI after upgrading to 8.0.
 
-```
+```shell
 # On your CI server:
 # Omnibus
 sudo gitlab-ctl stop ci-unicorn
@@ -171,7 +171,7 @@ GitLab server. On Omnibus GitLab servers you will have to add a line to
 `/etc/gitlab/gitlab.rb`. On GitLab servers installed from source you will have
 to replace the contents of `/home/git/gitlab/config/secrets.yml`.
 
-```
+```shell
 # On your CI server:
 # Omnibus
 sudo gitlab-ci-rake backup:show_secrets
@@ -188,7 +188,7 @@ PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
 the command finishes it will print the path to your data export archive; you
 will need this file later.
 
-```
+```shell
 # On your CI server:
 # Omnibus
 sudo chown gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
@@ -209,7 +209,7 @@ this, below we use SSH agent forwarding and 'scp', which will be easy and fast
 for most setups. You can also copy the data archive first from the CI server to
 your laptop and then from your laptop to the GitLab server.
 
-```
+```shell
 # Start from your laptop
 ssh -A ci_admin@ci_server.example
 # Now on the CI server
@@ -221,7 +221,7 @@ scp /path/to/12345_gitlab_ci_backup.tar gitlab_admin@gitlab_server.example:~
 Make the CI data archive discoverable for GitLab. We assume below that you
 store backups in the default path, adjust the command if necessary.
 
-```
+```shell
 # On your GitLab server:
 # Omnibus
 sudo mv /path/to/12345_gitlab_ci_backup.tar /var/opt/gitlab/backups/
@@ -235,7 +235,7 @@ sudo mv /path/to/12345_gitlab_ci_backup.tar /home/git/gitlab/tmp/backups/
 This step will delete any existing CI data on your GitLab server. There should
 be no CI data yet because you turned CI on the GitLab server off earlier.
 
-```
+```shell
 # On your GitLab server:
 # Omnibus
 sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
@@ -248,7 +248,7 @@ sudo -u git -H bundle exec rake ci:migrate RAILS_ENV=production
 
 ### 6. Restart GitLab
 
-```
+```shell
 # On your GitLab server:
 # Omnibus
 sudo gitlab-ctl hup unicorn
@@ -347,7 +347,7 @@ restoration](../raketasks/backup_restore.md) guide.
 
 If you see errors like this:
 
-```
+```plaintext
 Missing `secret_key_base` or `db_key_base` for 'production' environment. The secrets will be generated and stored in `config/secrets.yml`
 rake aborted!
 Errno::EACCES: Permission denied @ rb_sysopen - config/secrets.yml
@@ -360,13 +360,13 @@ The fix for this is to update to Omnibus 7.14 first and then update it to 8.0.
 
 To fix that issue you have to change builds/ folder permission before doing final backup:
 
-```
+```shell
 sudo chown -R gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
 ```
 
 Then before executing `ci:migrate` you need to fix builds folder permission:
 
-```
+```shell
 sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
 ```
 
@@ -450,7 +450,7 @@ EOF
 
 Source installations:
 
-```
+```shell
 cd /home/gitlab_ci/gitlab-ci
 sudo -u gitlab_ci -H bundle exec rails dbconsole production <<EOF
 ... COPY SQL STATEMENTS FROM ABOVE ...