Fix spacing of codeblocks in various docs

Without proper spacing, codeblocks will not color
correctly, so this aligns all codeblocks with the
list items they are nested beneath

doc/administration/auth/okta.md

@@ -86,9 +86,9 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
    Edit `config/gitlab.yml`:
-    ```yaml
-    auto_link_saml_user: true
-    ```
+   ```yaml
+   auto_link_saml_user: true
+   ```
 1. Add the provider configuration.

doc/administration/geo/replication/troubleshooting.md

@@ -167,7 +167,7 @@ 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
    ```plaintext

doc/administration/gitaly/praefect.md

@@ -121,7 +121,7 @@ node, using `psql` which is installed by GitLab Omnibus.
    ```sql
    CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD 'PRAEFECT_SQL_PASSWORD';
-    ```
+   ```
 1. Reconnect to the PostgreSQL server, this time as the `praefect` user:

doc/administration/monitoring/prometheus/index.md

@@ -135,9 +135,9 @@ To use an external Prometheus server:
 1. Install and set up a dedicated Prometheus instance, if necessary, using the [official installation instructions](https://prometheus.io/docs/prometheus/latest/installation/).
 1. Add the Prometheus server IP address to the [monitoring IP whitelist](../ip_whitelist.md). For example:
-    ```ruby
-    gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
-    ```
+   ```ruby
+   gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
+   ```
 1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server
    IP. For example:

doc/administration/pages/index.md

@@ -360,16 +360,16 @@ that method from working. Use the following workaround:
 1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
-    ```shell
-    printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
-    echo -n | openssl s_client -connect gitlab-domain-example.com:443  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
-    ```
+   ```shell
+   printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
+   echo -n | openssl s_client -connect gitlab-domain-example.com:443  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
+   ```
 1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
-    ```shell
-    sudo gitlab-ctl restart gitlab-pages
-    ```
+   ```shell
+   sudo gitlab-ctl restart gitlab-pages
+   ```
 CAUTION: **Caution:**
 Some GitLab Omnibus upgrades will revert this workaround and you'll need to apply it again.

doc/administration/static_objects_external_storage.md

@@ -63,158 +63,158 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr
      `pwgen -cn1 64` on a UNIX machine). Save this token for the admin panel, as
      described in the [configuring](#configuring) section.
-    ```js
-    const ORIGIN_HOSTNAME = 'gitlab.installation.com' // FIXME: SET CORRECT VALUE
-    const STORAGE_TOKEN = 'very-secure-token' // FIXME: SET CORRECT VALUE
-    const CACHE_PRIVATE_OBJECTS = false
-
-    const CORS_HEADERS = {
-      'Access-Control-Allow-Origin': '*',
-      'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS',
-      'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With',
-    }
-
-    self.addEventListener('fetch', event => event.respondWith(handle(event)))
-
-    async function handle(event) {
-      try {
-        let response = await verifyAndHandle(event);
-
-        // responses returned from cache are immutable, so we recreate them
-        // to set CORS headers
-        response = new Response(response.body, response)
-        response.headers.set('Access-Control-Allow-Origin', '*')
-
-        return response
-      } catch (e) {
-        return new Response('An error occurred!', {status: e.statusCode || 500})
-      }
-    }
-
-    async function verifyAndHandle(event) {
-      if (!validRequest(event.request)) {
-        return new Response(null, {status: 400})
-      }
-
-      if (event.request.method === 'OPTIONS') {
-        return handleOptions(event.request)
-      }
-
-      return handleRequest(event)
-    }
-
-    function handleOptions(request) {
-      // Make sure the necessary headers are present
-      // for this to be a valid pre-flight request
-      if (
-        request.headers.get('Origin') !== null &&
-        request.headers.get('Access-Control-Request-Method') !== null &&
-        request.headers.get('Access-Control-Request-Headers') !== null
-      ) {
-        // Handle CORS pre-flight request
-        return new Response(null, {
-          headers: CORS_HEADERS,
-        })
-      } else {
-        // Handle standard OPTIONS request
-        return new Response(null, {
-          headers: {
-            Allow: 'GET, HEAD, OPTIONS',
-          },
-        })
-      }
-    }
-
-    async function handleRequest(event) {
-      let cache = caches.default
-      let url = new URL(event.request.url)
-      let static_object_token = url.searchParams.get('token')
-      let headers = new Headers(event.request.headers)
-
-      url.host = ORIGIN_HOSTNAME
-      url = normalizeQuery(url)
-
-      headers.set('X-Gitlab-External-Storage-Token', STORAGE_TOKEN)
-      if (static_object_token !== null) {
-        headers.set('X-Gitlab-Static-Object-Token', static_object_token)
-      }
-
-      let request = new Request(url, { headers: headers })
-      let cached_response = await cache.match(request)
-      let is_conditional_header_set = headers.has('If-None-Match')
-
-      if (cached_response) {
-        return cached_response
-      }
-
-      // We don't want to override If-None-Match that is set on the original request
-      if (cached_response && !is_conditional_header_set) {
-        headers.set('If-None-Match', cached_response.headers.get('ETag'))
-      }
-
-      let response = await fetch(request, {
-        headers: headers,
-        redirect: 'manual'
-      })
-
-      if (response.status == 304) {
-        if (is_conditional_header_set) {
-          return response
-        } else {
-          return cached_response
-        }
-      } else if (response.ok) {
-        response = new Response(response.body, response)
-
-        // cache.put will never cache any response with a Set-Cookie header
-        response.headers.delete('Set-Cookie')
-
-        if (CACHE_PRIVATE_OBJECTS) {
-          response.headers.delete('Cache-Control')
-        }
-
-        event.waitUntil(cache.put(request, response.clone()))
-      }
-
-      return response
-    }
-
-    function normalizeQuery(url) {
-      let searchParams = url.searchParams
-      url = new URL(url.toString().split('?')[0])
-
-      if (url.pathname.includes('/raw/')) {
-        let inline = searchParams.get('inline')
-
-        if (inline == 'false' || inline == 'true') {
-          url.searchParams.set('inline', inline)
-        }
-      } else if (url.pathname.includes('/-/archive/')) {
-        let append_sha = searchParams.get('append_sha')
-        let path = searchParams.get('path')
-
-        if (append_sha == 'false' || append_sha == 'true') {
-          url.searchParams.set('append_sha', append_sha)
-        }
-        if (path) {
-          url.searchParams.set('path', path)
-        }
-      }
-
-      return url
-    }
-
-    function validRequest(request) {
-      let url = new URL(request.url)
-      let path = url.pathname
-
-      if (/^(.+)(\/raw\/|\/-\/archive\/)/.test(path)) {
-        return true
-      }
-
-      return false
-    }
-    ```
+     ```js
+     const ORIGIN_HOSTNAME = 'gitlab.installation.com' // FIXME: SET CORRECT VALUE
+     const STORAGE_TOKEN = 'very-secure-token' // FIXME: SET CORRECT VALUE
+     const CACHE_PRIVATE_OBJECTS = false
+
+     const CORS_HEADERS = {
+       'Access-Control-Allow-Origin': '*',
+       'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS',
+       'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With',
+     }
+
+     self.addEventListener('fetch', event => event.respondWith(handle(event)))
+
+     async function handle(event) {
+       try {
+         let response = await verifyAndHandle(event);
+
+         // responses returned from cache are immutable, so we recreate them
+         // to set CORS headers
+         response = new Response(response.body, response)
+         response.headers.set('Access-Control-Allow-Origin', '*')
+
+         return response
+       } catch (e) {
+         return new Response('An error occurred!', {status: e.statusCode || 500})
+       }
+     }
+
+     async function verifyAndHandle(event) {
+       if (!validRequest(event.request)) {
+         return new Response(null, {status: 400})
+       }
+
+       if (event.request.method === 'OPTIONS') {
+         return handleOptions(event.request)
+       }
+
+       return handleRequest(event)
+     }
+
+     function handleOptions(request) {
+       // Make sure the necessary headers are present
+       // for this to be a valid pre-flight request
+       if (
+         request.headers.get('Origin') !== null &&
+         request.headers.get('Access-Control-Request-Method') !== null &&
+         request.headers.get('Access-Control-Request-Headers') !== null
+       ) {
+         // Handle CORS pre-flight request
+         return new Response(null, {
+           headers: CORS_HEADERS,
+         })
+       } else {
+         // Handle standard OPTIONS request
+         return new Response(null, {
+           headers: {
+             Allow: 'GET, HEAD, OPTIONS',
+           },
+         })
+       }
+     }
+
+     async function handleRequest(event) {
+       let cache = caches.default
+       let url = new URL(event.request.url)
+       let static_object_token = url.searchParams.get('token')
+       let headers = new Headers(event.request.headers)
+
+       url.host = ORIGIN_HOSTNAME
+       url = normalizeQuery(url)
+
+       headers.set('X-Gitlab-External-Storage-Token', STORAGE_TOKEN)
+       if (static_object_token !== null) {
+         headers.set('X-Gitlab-Static-Object-Token', static_object_token)
+       }
+
+       let request = new Request(url, { headers: headers })
+       let cached_response = await cache.match(request)
+       let is_conditional_header_set = headers.has('If-None-Match')
+
+       if (cached_response) {
+         return cached_response
+       }
+
+       // We don't want to override If-None-Match that is set on the original request
+       if (cached_response && !is_conditional_header_set) {
+         headers.set('If-None-Match', cached_response.headers.get('ETag'))
+       }
+
+       let response = await fetch(request, {
+         headers: headers,
+         redirect: 'manual'
+       })
+
+       if (response.status == 304) {
+         if (is_conditional_header_set) {
+           return response
+         } else {
+           return cached_response
+         }
+       } else if (response.ok) {
+         response = new Response(response.body, response)
+
+         // cache.put will never cache any response with a Set-Cookie header
+         response.headers.delete('Set-Cookie')
+
+         if (CACHE_PRIVATE_OBJECTS) {
+           response.headers.delete('Cache-Control')
+         }
+
+         event.waitUntil(cache.put(request, response.clone()))
+       }
+
+       return response
+     }
+
+     function normalizeQuery(url) {
+       let searchParams = url.searchParams
+       url = new URL(url.toString().split('?')[0])
+
+       if (url.pathname.includes('/raw/')) {
+         let inline = searchParams.get('inline')
+
+         if (inline == 'false' || inline == 'true') {
+           url.searchParams.set('inline', inline)
+         }
+       } else if (url.pathname.includes('/-/archive/')) {
+         let append_sha = searchParams.get('append_sha')
+         let path = searchParams.get('path')
+
+         if (append_sha == 'false' || append_sha == 'true') {
+           url.searchParams.set('append_sha', append_sha)
+         }
+         if (path) {
+           url.searchParams.set('path', path)
+         }
+       }
+
+       return url
+     }
+
+     function validRequest(request) {
+       let url = new URL(request.url)
+       let path = url.pathname
+
+       if (/^(.+)(\/raw\/|\/-\/archive\/)/.test(path)) {
+         return true
+       }
+
+       return false
+     }
+     ```
 1. Create a new worker with this script.
 1. Copy your values for `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -202,9 +202,9 @@ and they will assist you with any issues you are having.
 - How to get the manifest for a release. It can be useful because it contains the info about
 all Kubernetes resources and dependent charts:
-    ```shell
-    helm get manifest <release name>
-    ```
+  ```shell
+  helm get manifest <release name>
+  ```
 ## Installation of minimal GitLab config via Minukube on macOS

doc/ci/docker/using_docker_build.md

@@ -127,14 +127,14 @@ not without its own challenges:
   and use it as your mount point (for a more thorough explanation, check [issue
   #41227](https://gitlab.com/gitlab-org/gitlab-foss/issues/41227)):
-    ```yaml
-    variables:
-      MOUNT_POINT: /builds/$CI_PROJECT_PATH/mnt
-    script:
-      - mkdir -p "$MOUNT_POINT"
-      - docker run -v "$MOUNT_POINT:/mnt" my-docker-image
-    ```
+  ```yaml
+  variables:
+    MOUNT_POINT: /builds/$CI_PROJECT_PATH/mnt
+  script:
+    - mkdir -p "$MOUNT_POINT"
+    - docker run -v "$MOUNT_POINT:/mnt" my-docker-image
+  ```
 An example project using this approach can be found here: <https://gitlab.com/gitlab-examples/docker>.
@@ -198,7 +198,7 @@ support this.
      [runners.cache]
        [runners.cache.s3]
        [runners.cache.gcs]
-    ```
+   ```
 1. You can now use `docker` in the build script (note the inclusion of the
    `docker:19.03.1-dind` service):

doc/development/application_limits.md

@@ -22,22 +22,22 @@ limit values. It's recommended to create separate migration script files.
 1. Add new column to the `plan_limits` table with non-null default value 0, eg:
-    ```ruby
-    add_column(:plan_limits, :project_hooks, :integer, default: 0, null: false)
-    ```
-    NOTE: **Note:** Plan limits entries set to `0` mean that limits are not
-    enabled.
+   ```ruby
+   add_column(:plan_limits, :project_hooks, :integer, default: 0, null: false)
+   ```
+   NOTE: **Note:** Plan limits entries set to `0` mean that limits are not
+   enabled.
 1. Insert plan limits values into the database using
    `create_or_update_plan_limit` migration helper, eg:
-    ```ruby
-    create_or_update_plan_limit('project_hooks', 'free', 10)
-    create_or_update_plan_limit('project_hooks', 'bronze', 20)
-    create_or_update_plan_limit('project_hooks', 'silver', 30)
-    create_or_update_plan_limit('project_hooks', 'gold', 100)
-    ```
+   ```ruby
+   create_or_update_plan_limit('project_hooks', 'free', 10)
+   create_or_update_plan_limit('project_hooks', 'bronze', 20)
+   create_or_update_plan_limit('project_hooks', 'silver', 30)
+   create_or_update_plan_limit('project_hooks', 'gold', 100)
+   ```
 ### Plan limits validation

doc/development/documentation/site_architecture/release_process.md

@@ -70,9 +70,9 @@ this needs to happen when the stable branches for all products have been created
 1. Run the raketask to create the single version:
-    ```shell
-    ./bin/rake "release:single[12.0]"
-    ```
+   ```shell
+   ./bin/rake "release:single[12.0]"
+   ```
     A new `Dockerfile.12.0` should have been created and committed to a new branch.

doc/development/import_project.md

@@ -115,13 +115,13 @@ The last option is to import a project using a Rails console:
                                           project: project).restore
    ```
-    We are storing all import failures in the `import_failures` data table.
-    To make sure that the project import finished without any issues, check:
-    ```ruby
-    project.import_failures.all
-    ```
+   We are storing all import failures in the `import_failures` data table.
+   To make sure that the project import finished without any issues, check:
+   ```ruby
+   project.import_failures.all
+   ```
 ## Performance testing

doc/integration/vault.md

@@ -15,106 +15,109 @@ The following assumes you already have Vault installed and running.
 1. **Get the OpenID Connect client ID and secret from GitLab:**
-    First you'll need to create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
-    1. On GitLab, click your avatar on the top-right corner, and select your user **Settings > Applications**.
-    1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris),
-       making sure to select the **OpenID** scope.
-    1. Save application.
-    1. Copy client ID and secret, or keep the page open for reference.
-    ![GitLab OAuth provider](img/gitlab_oauth_vault_v12_6.png)
+   First you'll need to create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
+   1. On GitLab, click your avatar on the top-right corner, and select your user **Settings > Applications**.
+   1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris),
+      making sure to select the **OpenID** scope.
+   1. Save application.
+   1. Copy client ID and secret, or keep the page open for reference.
+
+   ![GitLab OAuth provider](img/gitlab_oauth_vault_v12_6.png)
 1. **Enable OIDC auth on Vault:**
-    OpenID Connect is not enabled in Vault by default. This needs to be enabled in the terminal.
-    Open a terminal session and run the following command to enable the OpenID Connect authentication provider in Vault:
-    ```shell
-    vault auth enable oidc
-    ```
-    You should see the following output in the terminal:
-    ```plaintext
-    Success! Enabled oidc auth method at: oidc/
-    ```
+   OpenID Connect is not enabled in Vault by default. This needs to be enabled in the terminal.
+   Open a terminal session and run the following command to enable the OpenID Connect authentication provider in Vault:
+   ```shell
+   vault auth enable oidc
+   ```
+   You should see the following output in the terminal:
+   ```plaintext
+   Success! Enabled oidc auth method at: oidc/
+   ```
 1. **Write the OIDC config:**
-    Next, Vault needs to be given the application ID and secret generated by GitLab.
-    In the terminal session, run the following command to give Vault access to the GitLab application you've just created with an OpenID scope. This allows Vault to authenticate through GitLab.
-    Replace `your_application_id` and `your_secret` in the example below with the application ID and secret generated for your app:
-    ```shell
-    $ vault write auth/oidc/config \
-        oidc_discovery_url="https://gitlab.com" \
-        oidc_client_id="your_application_id" \
-        oidc_client_secret="your_secret" \
-        default_role="demo" \
-        bound_issuer="localhost"
-    ```
-    You should see the following output in the terminal:
-    ```shell
-    Success! Data written to: auth/oidc/config
-    ```
+   Next, Vault needs to be given the application ID and secret generated by GitLab.
+   In the terminal session, run the following command to give Vault access to the GitLab application you've just created with an OpenID scope. This allows Vault to authenticate through GitLab.
+   Replace `your_application_id` and `your_secret` in the example below with the application ID and secret generated for your app:
+   ```shell
+   $ vault write auth/oidc/config \
+       oidc_discovery_url="https://gitlab.com" \
+       oidc_client_id="your_application_id" \
+       oidc_client_secret="your_secret" \
+       default_role="demo" \
+       bound_issuer="localhost"
+   ```
+   You should see the following output in the terminal:
+   ```shell
+   Success! Data written to: auth/oidc/config
+   ```
 1. **Write the OIDC Role Config:**
-    Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
-    This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.
-    ```shell
-    vault write auth/oidc/role/demo \
-          user_claim="sub" \
-          allowed_redirect_uris="http://localhost:8250/oidc/callback,http://127.0.0.1:8200/ui/vault/auth/oidc/oidc/callback" \
-          bound_audiences="your_application_id" \
-          role_type="oidc" \
-          oidc_scopes="openid" \
-          policies=demo \
-          ttl=1h
-    ```
+   Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
+   This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.
+   ```shell
+   vault write auth/oidc/role/demo \
+         user_claim="sub" \
+         allowed_redirect_uris="http://localhost:8250/oidc/callback,http://127.0.0.1:8200/ui/vault/auth/oidc/oidc/callback" \
+         bound_audiences="your_application_id" \
+         role_type="oidc" \
+         oidc_scopes="openid" \
+         policies=demo \
+         ttl=1h
+   ```
 1. **Sign in to Vault:**
-    1. Go to your Vault UI (example: [http://127.0.0.1:8200/ui/vault/auth?with=oidc](http://127.0.0.1:8200/ui/vault/auth?with=oidc)).
-    1. If the `OIDC` method is not currently selected, open the dropdown and select it.
-    1. Click the **Sign in With GitLab** button, which will open a modal window:
-    ![Sign into Vault with GitLab](img/sign_into_vault_with_gitlab_v12_6.png)
-    1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This will redirect you back to your Vault UI as a signed-in user.
-    ![Authorize Vault to connect with GitLab](img/authorize_vault_with_gitlab_v12_6.png)
+   1. Go to your Vault UI (example: [http://127.0.0.1:8200/ui/vault/auth?with=oidc](http://127.0.0.1:8200/ui/vault/auth?with=oidc)).
+   1. If the `OIDC` method is not currently selected, open the dropdown and select it.
+   1. Click the **Sign in With GitLab** button, which will open a modal window:
+
+   ![Sign into Vault with GitLab](img/sign_into_vault_with_gitlab_v12_6.png)
+
+   1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This will redirect you back to your Vault UI as a signed-in user.
+   ![Authorize Vault to connect with GitLab](img/authorize_vault_with_gitlab_v12_6.png)
 1. **Sign in using the Vault CLI** (optional):
-    Vault also allows you to sign in via their CLI.
-    After writing the same configurations from above, you can run the command below in your terminal to sign in with the role configuration created in step 4 above:
-    ```shell
-    vault login -method=oidc port=8250 role=demo
-    ```
-    Here is a short explaination of what this command does:
-    1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
-    1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
-    1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris).
-    Once you run the command above, it will present a link in the terminal.
-    Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
-    ![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
-    The terminal will output:
-    ```plaintext
-    Success! You are now authenticated. The token information displayed below
-    is already stored in the token helper. You do NOT need to run "vault login"
-    again. Future Vault requests will automatically use this token.
-    ```
+   Vault also allows you to sign in via their CLI.
+   After writing the same configurations from above, you can run the command below in your terminal to sign in with the role configuration created in step 4 above:
+   ```shell
+   vault login -method=oidc port=8250 role=demo
+   ```
+   Here is a short explaination of what this command does:
+   1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
+   1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
+   1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris).
+   Once you run the command above, it will present a link in the terminal.
+   Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
+   ![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
+   The terminal will output:
+   ```plaintext
+   Success! You are now authenticated. The token information displayed below
+   is already stored in the token helper. You do NOT need to run "vault login"
+   again. Future Vault requests will automatically use this token.
+   ```

doc/user/application_security/container_scanning/index.md

@@ -270,9 +270,9 @@ image directly, follow these steps:
 1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop) or [Docker Machine](https://github.com/docker/machine).
 1. Run the latest [prefilled vulnerabilities database](https://cloud.docker.com/repository/docker/arminc/clair-db) Docker image:
-    ```shell
-    docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
-    ```
+   ```shell
+   docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
+   ```
 1. Configure an environment variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step):
@@ -282,16 +282,16 @@ image directly, follow these steps:
 1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` environment variables:
-    ```shell
-    docker run \
-      --interactive --rm \
-      --volume "$PWD":/tmp/app \
-      -e CI_PROJECT_DIR=/tmp/app \
-      -e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
-      -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
-      -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
-      registry.gitlab.com/gitlab-org/security-products/analyzers/klar
-    ```
+   ```shell
+   docker run \
+     --interactive --rm \
+     --volume "$PWD":/tmp/app \
+     -e CI_PROJECT_DIR=/tmp/app \
+     -e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
+     -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
+     -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
+     registry.gitlab.com/gitlab-org/security-products/analyzers/klar
+   ```
 The results are stored in `gl-container-scanning-report.json`.

doc/user/clusters/applications.md

@@ -501,20 +501,20 @@ To install applications using GitLab CI:
 1. Connect the cluster to a [cluster management project](management_project.md).
 1. In that project, add a `.gitlab-ci.yml` file with the following content:
-    ```yaml
-    include:
-      - template: Managed-Cluster-Applications.gitlab-ci.yml
-    ```
+   ```yaml
+   include:
+     - template: Managed-Cluster-Applications.gitlab-ci.yml
+   ```
 1. Add a `.gitlab/managed-apps/config.yaml` file to define which
   applications you would like to install. Define the `installed` key as
   `true` to install the application and `false` to uninstall the
   application. For example, to install Ingress:
-    ```yaml
-    ingress:
-      installed: true
-    ```
+   ```yaml
+   ingress:
+     installed: true
+   ```
 1. Optionally, define `.gitlab/managed-apps/<application>/values.yaml` file to
    customize values for the installed application.