Merge branch '20200324-aqualls-codeblocks2' into 'master'

Add languages to code blocks

See merge request gitlab-org/gitlab!27923

doc/development/geo.md

@@ -134,7 +134,7 @@ The **secondary** node authenticates itself via a [JWT request](https://jwt.io/)
 When the **secondary** node wishes to download a file, it sends an
 HTTP request with the `Authorization` header:
 
-```
+```plaintext
 Authorization: GL-Geo <access_key>:<JWT payload>
 ```
 
@@ -146,7 +146,7 @@ file for the right database ID. For example, for an LFS object, the
 request must also include the SHA256 sum of the file. An example JWT
 payload looks like:
 
-```
+```yaml
 { "data": { sha256: "31806bb23580caab78040f8c45d329f5016b0115" }, iat: "1234567890" }
 ```
 
@@ -199,13 +199,13 @@ contains the schema and migrations for this database.
 
 To write a migration for the database, use the `GeoMigrationGenerator`:
 
-```
+```shell
 rails g geo_migration [args] [options]
 ```
 
 To migrate the tracking database, run:
 
-```
+```shell
 bundle exec rake geo:db:migrate
 ```
 
@@ -252,7 +252,7 @@ Failure to do this will prevent the **secondary** node from
 functioning properly. The **secondary** node will generate error
 messages, as the following PostgreSQL error:
 
-```
+```sql
 ERROR:  relation "gitlab_secondary.ci_job_artifacts" does not exist at character 323
 STATEMENT:                SELECT a.attname, format_type(a.atttypid, a.atttypmod),
                           pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod

doc/development/gotchas.md

@@ -101,7 +101,7 @@ end
   in a prepended module, which is very likely the case in EE. We could see
   error like this:
 
-  ```
+  ```plaintext
   1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages)
        Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
   ```

doc/development/i18n/externalization.md

@@ -488,7 +488,7 @@ The linter will take the following into account:
 
 The errors are grouped per file, and per message ID:
 
-```
+```plaintext
 Errors in `locale/zh_HK/gitlab.po`:
   PO-syntax errors
     SimplePoParser::ParserErrorSyntax error in lines

doc/development/import_export.md

@@ -63,7 +63,7 @@ class StuckImportJobsWorker
 Marked stuck import jobs as failed. JIDs: xyz
 ```
 
-```
+```plaintext
   +-----------+    +-----------------------------------+
   |Export Job |--->| Calls ActiveRecord `as_json` and  |
   +-----------+    | `to_json` on all project models   |

doc/development/import_project.md

@@ -148,7 +148,7 @@ In this section we'll detail any known issues we've seen when trying to import a
 
 If you're attempting to import a large project into a development environment, you may see Gitaly throw an error about too many calls or invocations, for example:
 
-```
+```plaintext
 Error importing repository into qa-perf-testing/gitlabhq - GitalyClient#call called 31 times from single request. Potential n+1?
 ```
 

doc/development/instrumentation.md

@@ -87,7 +87,7 @@ Ruby code. In case of the above snippet you'd run the following:
 
 This will print out something along the lines of:
 
-```
+```plaintext
 From: /path/to/your/gitlab/lib/gitlab/metrics/instrumentation.rb @ line 148:
 Owner: #<Module:0x0055f0865c6d50>
 Visibility: public

doc/development/integrations/jira_connect.md

@@ -31,7 +31,7 @@ The following are required to install and test the app:
 
       For example:
 
-      ```
+      ```plaintext
       https://xxxx.serveo.net/-/jira_connect/app_descriptor.json
       ```
 

doc/development/internal_api.md

@@ -34,7 +34,7 @@ Gitaly.
 When called from Gitaly in a `pre-receive` hook the changes are passed
 and those are validated to determine if the push is allowed.
 
-```
+```plaintext
 POST /internal/allowed
 ```
 
@@ -57,7 +57,7 @@ curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --da
 
 Example response:
 
-```
+```json
 {
   "status": true,
   "gl_repository": "project-3",
@@ -103,7 +103,7 @@ Example request:
 curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --data "key_id=11&project=gnuwget/wget2" http://localhost:3001/api/v4/internal/lfs_authenticate
 ```
 
-```
+```json
 {
   "username": "root",
   "lfs_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7ImFjdG9yIjoicm9vdCJ9LCJqdGkiOiIyYWJhZDcxZC0xNDFlLTQ2NGUtOTZlMi1mODllYWRiMGVmZTYiLCJpYXQiOjE1NzAxMTc2NzYsIm5iZiI6MTU3MDExNzY3MSwiZXhwIjoxNTcwMTE5NDc2fQ.g7atlBw1QMY7QEBVPE0LZ8ZlKtaRzaMRmNn41r2YITM",
@@ -126,7 +126,7 @@ lookup](../administration/operations/fast_ssh_key_lookup.md).
 |:----------|:-------|:---------|:------------|
 | `key`     | string | yes      | SSH key as passed by OpenSSH to GitLab-shell |
 
-```
+```plaintext
 GET /internal/authorized_keys
 ```
 
@@ -138,7 +138,7 @@ curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>""http
 
 Example response:
 
-```
+```json
 {
   "id": 11,
   "title": "admin@example.com",
@@ -161,7 +161,7 @@ discovers the user associated with an SSH key.
 | `key_id` | integer | no | The id of the SSH key used as found in the authorized-keys file or through the `/authorized_keys` check |
 | `username` | string | no | Username of the user being looked up, used by GitLab-shell when authenticating using a certificate |
 
-```
+```plaintext
 GET /internal/discover
 ```
 
@@ -173,7 +173,7 @@ curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>" "htt
 
 Example response:
 
-```
+```json
 {
   "id": 7,
   "name": "Dede Eichmann",
@@ -190,7 +190,7 @@ Example response:
 This get's some generic information about the instance. This is used
 by Geo nodes to get information about eachother
 
-```
+```plaintext
 GET /internal/check
 ```
 
@@ -202,7 +202,7 @@ curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>" "htt
 
 Example response:
 
-```
+```json
 {
   "api_version": "v4",
   "gitlab_version": "12.3.0-pre",
@@ -226,7 +226,7 @@ recovery codes based on their SSH key
 | `key_id`  | integer | no | The id of the SSH key used as found in the authorized-keys file or through the `/authorized_keys` check |
 | `user_id` | integer | no | **Deprecated** User_id for which to generate new recovery codes |
 
-```
+```plaintext
 GET /internal/two_factor_recovery_codes
 ```
 
@@ -238,7 +238,7 @@ curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --d
 
 Example response:
 
-```
+```json
 {
   "success": true,
   "recovery_codes": [
@@ -269,7 +269,7 @@ for a push that might be accepted.
 |:----------|:-------|:---------|:------------|
 | `gl_repository` | string | yes | repository identifier for the repository receiving the push |
 
-```
+```plaintext
 POST /internal/pre_receive
 ```
 
@@ -281,7 +281,7 @@ curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --d
 
 Example response:
 
-```
+```json
 {
   "reference_counter_increased": true
 }
@@ -301,7 +301,7 @@ the user.
 | `push_options` | string array | no | array of push options |
 | `changes` | string | no | refs to be updated in the push in the format `oldrev newrev refname\n`. |
 
-```
+```plaintext
 POST /internal/post_receive
 ```
 
@@ -313,7 +313,7 @@ curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --d
 
 Example response:
 
-```
+```json
 {
   "messages": [
     {

doc/development/new_fe_guide/development/accessibility.md

@@ -27,7 +27,7 @@ On the other hand, if an icon is crucial to understand the context we should do
 
 In forms we should use the `for` attribute in the label statement:
 
-```
+```html
 <div>
   <label for="name">Fill in your name:</label>
   <input type="text" id="name" name="name">

doc/development/new_fe_guide/tips.md

@@ -4,7 +4,7 @@
 
 To clear production compiled assets created with `yarn webpack-prod` you can run:
 
-```
+```shell
 yarn clean
 ```
 

doc/development/routing.md

@@ -7,13 +7,13 @@ support subgroups, GitLab project and group routes use the wildcard
 character to match project and group routes. For example, we might have
 a path such as:
 
-```
+```plaintext
 /gitlab-com/customer-success/north-america/west/customerA
 ```
 
 However, paths can be ambiguous. Consider the following example:
 
-```
+```plaintext
 /gitlab-com/edit
 ```
 
@@ -29,7 +29,7 @@ number of [reserved names](../user/reserved_names.md).
 
 We have a number of global routes. For example:
 
-```
+```plaintext
 /-/health
 /-/metrics
 ```
@@ -40,7 +40,7 @@ Every group route must be under the `/-/` scope.
 
 Examples:
 
-```
+```plaintext
 gitlab-org/-/edit
 gitlab-org/-/activity
 gitlab-org/-/security/dashboard
@@ -56,7 +56,7 @@ client or other software requires something different.
 
 Examples:
 
-```
+```plaintext
 gitlab-org/gitlab/-/activity
 gitlab-org/gitlab/-/jobs/123
 gitlab-org/gitlab/-/settings/repository

doc/development/shell_commands.md

@@ -71,19 +71,21 @@ Make the difference between options and arguments clear to the argument parsers
 
 To understand what `--` does, consider the problem below.
 
-```
+```shell
 # Example
 $ echo hello > -l
 $ cat -l
+
 cat: illegal option -- l
 usage: cat [-benstuv] [file ...]
 ```
 
 In the example above, the argument parser of `cat` assumes that `-l` is an option. The solution in the example above is to make it clear to `cat` that `-l` is really an argument, not an option. Many Unix command line tools follow the convention of separating options from arguments with `--`.
 
-```
+```shell
 # Example (continued)
 $ cat -- -l
+
 hello
 ```
 
@@ -203,7 +205,7 @@ validates :import_url, format: { with: URI.regexp(%w(ssh git http https)) }
 
 Suppose the user submits the following as their import URL:
 
-```
+```plaintext
 file://git:/tmp/lol
 ```
 

doc/install/installation.md

@@ -329,7 +329,7 @@ use of extensions and concurrent index removal, you need at least PostgreSQL 9.2
 
 1. Check if the `pg_trgm` extension is enabled:
 
-   ```shell
+   ```sql
    SELECT true AS enabled
    FROM pg_available_extensions
    WHERE name = 'pg_trgm'
@@ -338,7 +338,7 @@ use of extensions and concurrent index removal, you need at least PostgreSQL 9.2
 
    If the extension is enabled this will produce the following output:
 
-   ```
+   ```plaintext
    enabled
    ---------
     t

doc/integration/gitlab.md

@@ -15,7 +15,7 @@ GitLab.com will generate an application ID and secret key for you to use.
    - Name: This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive.
    - Redirect URI:
 
-   ```
+   ```plaintext
    http://your-gitlab.example.com/import/gitlab/callback
    http://your-gitlab.example.com/users/auth/gitlab/callback
    ```
@@ -63,7 +63,7 @@ GitLab.com will generate an application ID and secret key for you to use.
 
    For installations from source:
 
-   ```
+   ```yaml
    - { name: 'gitlab', app_id: 'YOUR_APP_ID',
      app_secret: 'YOUR_APP_SECRET',
      args: { scope: 'api' } }

doc/integration/google.md

@@ -28,7 +28,7 @@ In Google's side:
    - **Authorized redirect URIs** - Enter your domain name followed by the
      callback URIs one at a time:
 
-     ```
+     ```plaintext
      https://gitlab.example.com/users/auth/google_oauth2/callback
      https://gitlab.example.com/-/google_api/auth/callback
      ```

doc/integration/jenkins.md

@@ -160,7 +160,7 @@ in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` comman
 If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this
 could also indicate that [webhook requests are timing out](../user/project/integrations/webhooks.md#receiving-duplicate-or-multiple-webhook-requests-triggered-by-one-event):
 
-```
+```plaintext
 2019-10-25_04:22:41.25630 2019-10-25T04:22:41.256Z 1584 TID-ovowh4tek WebHookWorker JID-941fb7f40b69dff3d833c99b INFO: start
 2019-10-25_04:22:41.25630 2019-10-25T04:22:41.256Z 1584 TID-ovowh4tek WebHookWorker JID-941fb7f40b69dff3d833c99b INFO: start
 ```

doc/integration/kerberos.md

@@ -33,7 +33,7 @@ system's Kerberos settings.
 The keytab is a sensitive file and must be readable by the GitLab user. Set
 ownership and protect the file appropriately:
 
-```
+```shell
 sudo chown git /etc/http.keytab
 sudo chmod 0600 /etc/http.keytab
 ```
@@ -243,7 +243,7 @@ With Kerberos SPNEGO authentication, the browser is expected to send a list of
 mechanisms it supports to GitLab. If it doesn't support any of the mechanisms
 GitLab supports, authentication will fail with a message like this in the log:
 
-```
+```plaintext
 OmniauthKerberosSpnegoController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested Unknown error
 ```
 
@@ -282,7 +282,7 @@ fatal: Authentication failed for '<KRB5 path>'
 If you are using Git v2.11 or newer and see the above error when cloning, you can
 set the `http.emptyAuth` Git option to `true` to fix this:
 
-```
+```shell
 git config --global http.emptyAuth true
 ```
 

doc/integration/oauth2_generic.md

@@ -26,7 +26,7 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
 
    The redirect URI you provide when registering the application should be:
 
-   ```
+   ```plaintext
    http://your-gitlab.host.com/users/auth/oauth2_generic/callback
    ```
 

doc/integration/recaptcha.md

@@ -23,7 +23,7 @@ user logins via passwords, the `X-GitLab-Show-Login-Captcha` HTTP header must
 be set. For example, in NGINX, this can be done via the `proxy_set_header`
 configuration variable:
 
-```
+```nginx
 proxy_set_header X-GitLab-Show-Login-Captcha 1;
 ```
 

doc/integration/salesforce.md

@@ -60,7 +60,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
 
    For installation from source:
 
-   ```
+   ```yaml
    - { name: 'salesforce',
        app_id: 'SALESFORCE_CLIENT_ID',
        app_secret: 'SALESFORCE_CLIENT_SECRET'

doc/integration/saml.md

@@ -129,7 +129,7 @@ To ease configuration, most IdP accept a metadata URL for the application to pro
 configuration information to the IdP. To build the metadata URL for GitLab, append
 `users/auth/saml/metadata` to the HTTPS URL of your GitLab installation, for instance:
 
-```
+```plaintext
 https://gitlab.example.com/users/auth/saml/metadata
 ```
 

doc/integration/shibboleth.md

@@ -66,7 +66,7 @@ The following changes are needed to enable Shibboleth:
 
    The file should look like this:
 
-   ```
+   ```ruby
    external_url 'https://gitlab.example.com'
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
@@ -101,7 +101,7 @@ On the sign in page, there should now be a "Sign in with: Shibboleth" icon below
 The order of the first 2 Location directives is important. If they are reversed,
 you will not get a Shibboleth session!
 
-```
+```plaintext
 <Location />
   Require all granted
   ProxyPassReverse http://127.0.0.1:8181

doc/raketasks/user_management.md

@@ -52,7 +52,7 @@ bundle exec rake gitlab:import:all_users_to_all_groups RAILS_ENV=production
 
 - Enable this setting to keep new users blocked until they have been cleared by the admin (default: false).
 
-```
+```plaintext
 block_auto_created_users: false
 ```
 

doc/security/rack_attack.md

@@ -177,13 +177,13 @@ In case you want to remove a blocked IP, follow these steps:
 1. You can remove the block using the following syntax, replacing `<ip>` with
    the actual IP that is blacklisted:
 
-   ```
+   ```plaintext
    del cache:gitlab:rack::attack:allow2ban:ban:<ip>
    ```
 
 1. Confirm that the key with the IP no longer shows up:
 
-   ```
+   ```plaintext
    keys *rack::attack*
    ```
 

doc/topics/airgap/quick_start_guide.md

@@ -150,7 +150,7 @@ sudo update-ca-certificates
 
 If all goes well, this is what you should see:
 
-```
+```plaintext
 1 added, 0 removed; done.
 Running hooks in /etc/ca-certificates/update.d...
 done.

doc/topics/autodevops/quick_start_guide.md

@@ -239,7 +239,7 @@ After a few minutes you'll notice that there was a failure in a test.
 This means there's a test that was 'broken' by our change.
 Navigating into the `test` job that failed, you can see what the broken test is:
 
-```
+```plaintext
 Failure:
 WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
 <You're on Rails!> expected but was

doc/university/training/user_training.md

@@ -294,7 +294,7 @@ git push origin <branch> -f
 
 You may end up with a commit log that looks like this:
 
-```
+```plaintext
 Fix issue #13
 Test
 Fix

doc/user/application_security/dast/index.md

@@ -217,7 +217,7 @@ It's also possible to add the `Gitlab-DAST-Permission` header via a proxy.
 
 The following config allows NGINX to act as a reverse proxy and add the `Gitlab-DAST-Permission` [header](http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header):
 
-```
+```nginx
 # default.conf
 server {
     listen 80;
@@ -237,7 +237,7 @@ to add the `Gitlab-DAST-Permission` [header](https://httpd.apache.org/docs/curre
 
 To do so, add the following lines to `httpd.conf`:
 
-```
+```plaintext
 # httpd.conf
 LoadModule proxy_module modules/mod_proxy.so
 LoadModule proxy_connect_module modules/mod_proxy_connect.so
@@ -472,7 +472,7 @@ Since it keeps most of its information in memory during a scan,
 it is possible for DAST to run out of memory while scanning large applications.
 This results in the following error:
 
-```
+```plaintext
 [zap.out] java.lang.OutOfMemoryError: Java heap space
 ```
 

doc/user/application_security/sast/index.md

@@ -518,7 +518,7 @@ For SAST with all [supported languages and frameworks](#supported-languages-and-
 import the following default SAST analyzer images from `registry.gitlab.com` to your local "offline"
 registry:
 
-```
+```plaintext
 registry.gitlab.com/gitlab-org/security-products/analyzers/bandit:2
 registry.gitlab.com/gitlab-org/security-products/analyzers/brakeman:2
 registry.gitlab.com/gitlab-org/security-products/analyzers/eslint:2

doc/user/asciidoc.md

@@ -17,7 +17,7 @@ Line breaks are not preserved.
 
 Line comments, which are lines that start with `//`, are skipped:
 
-```
+```asciidoc
 // this is a comment
 ```
 

doc/user/packages/npm_registry/index.md

@@ -224,7 +224,7 @@ it is not possible due to a naming collision. For example:
 
 The regex that is used for naming is validating all package names from all package managers:
 
-```
+```plaintext
 /\A\@?(([\w\-\.\+]*)\/)*([\w\-\.]+)@?(([\w\-\.\+]*)\/)*([\w\-\.]*)\z/
 ```
 

doc/user/project/clusters/serverless/aws.md

@@ -140,7 +140,7 @@ NOTE: **Note:**
 In your GitLab deploy stage log, there will be output containing your AWS Lambda endpoint URL.
 The log line will look similar to this:
 
-```
+```plaintext
 endpoints:
   GET - https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello
 ```

doc/user/project/code_owners.md

@@ -29,7 +29,7 @@ the users from last pattern matching the file are displayed on the
 blob page of the given file. For example, you have the following
 `CODEOWNERS` file:
 
-```
+```plaintext
 README.md @user1
 
 # This line would also match the file README.md
@@ -68,7 +68,7 @@ escaped using `\#` to address files for which the name starts with a
 
 Example `CODEOWNERS` file:
 
-```
+```plaintext
 # This is an example code owners file, lines starting with a `#` will
 # be ignored.
 

doc/user/project/new_ci_build_permissions_model.md

@@ -213,7 +213,7 @@ project for which the job is triggered.
 
 This is how an example usage can look like:
 
-```
+```yaml
 test:
   script:
     - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY