Merge branch 'docs-code-block-style-7' into 'master'

Fix whitespace in user and misc docs

See merge request gitlab-org/gitlab-ce!30605

doc/migrate_ci_to_ce/README.md

@@ -181,7 +181,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production
 ### 2. SQL data and build traces
 
 Create your final CI data export. If you are converting from MySQL to
-  PostgreSQL, add ` MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
+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.
 
@@ -323,11 +323,15 @@ You should also make sure that you can:
 
 ### 2. Check Nginx configuration
 
-    sudo nginx -t
+```sh
+sudo nginx -t
+```
 
 ### 3. Restart Nginx
 
-    sudo /etc/init.d/nginx restart
+```sh
+sudo /etc/init.d/nginx restart
+```
 
 ### Restore from backup
 
@@ -352,11 +356,13 @@ The fix for this is to update to Omnibus 7.14 first and then update it to 8.0.
 ### Permission denied when accessing /var/opt/gitlab/gitlab-ci/builds
 
 To fix that issue you have to change builds/ folder permission before doing final backup:
+
 ```
 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:
+
 ```
 sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
 ```
@@ -365,7 +371,7 @@ sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
 
 If you were migrating CI database from MySQL to PostgreSQL manually you can see errors during import about missing sequences:
 
-```sql 
+```sql
 ALTER SEQUENCE
 ERROR:  relation "ci_builds_id_seq" does not exist
 ERROR:  relation "ci_commits_id_seq" does not exist

doc/security/rack_attack.md

@@ -34,34 +34,34 @@ For more information on how to use these options check out
 1. Open `/etc/gitlab/gitlab.rb` with your editor
 1. Add the following:
 
-    ```ruby
-    gitlab_rails['rack_attack_git_basic_auth'] = {
-      'enabled' => true,
-      'ip_whitelist' => ["127.0.0.1"],
-      'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
-      'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
-      'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
-    }
-    ```
+   ```ruby
+   gitlab_rails['rack_attack_git_basic_auth'] = {
+     'enabled' => true,
+     'ip_whitelist' => ["127.0.0.1"],
+     'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
+     'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
+     'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
+   }
+   ```
 
 1. Reconfigure GitLab:
 
-    ```
-    sudo gitlab-ctl reconfigure
-    ```
+   ```
+   sudo gitlab-ctl reconfigure
+   ```
 
 The following settings can be configured:
 
 - `enabled`: By default this is set to `false`. Set this to `true` to enable Rack Attack.
 - `ip_whitelist`: Whitelist any IPs from being blocked. They must be formatted as strings within a Ruby array.
-   CIDR notation is supported in GitLab v12.1 and up.
-   For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"]`.
+  CIDR notation is supported in GitLab v12.1 and up.
+  For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"]`.
 - `maxretry`: The maximum amount of times a request can be made in the
-   specified time.
+  specified time.
 - `findtime`: The maximum amount of time that failed requests can count against an IP
-   before it's blacklisted (in seconds).
+  before it's blacklisted (in seconds).
 - `bantime`: The total amount of time that a blacklisted IP will be blocked (in
-   seconds).
+  seconds).
 
 **Installations from source**
 
@@ -71,18 +71,18 @@ taken in order to enable protection for your GitLab instance:
 
 1. In `config/application.rb` find and uncomment the following line:
 
-    ```ruby
-    config.middleware.use Rack::Attack
-    ```
+   ```ruby
+   config.middleware.use Rack::Attack
+   ```
 
 1. Copy `config/initializers/rack_attack.rb.example` to `config/initializers/rack_attack.rb`
 1. Open `config/initializers/rack_attack.rb`, review the
    `paths_to_be_protected`, and add any other path you need protecting
 1. Restart GitLab:
 
-    ```sh
-    sudo service gitlab restart
-    ```
+   ```sh
+   sudo service gitlab restart
+   ```
 
 If you want more restrictive/relaxed throttle rules, edit
 `config/initializers/rack_attack.rb` and change the `limit` or `period` values.
@@ -98,28 +98,28 @@ In case you want to remove a blocked IP, follow these steps:
 
 1. Find the IPs that have been blocked in the production log:
 
-    ```sh
-    grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
-    ```
+   ```sh
+   grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
+   ```
 
 1. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
 
-    ```sh
-    /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
-    ```
+   ```sh
+   /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
+   ```
 
 1. You can remove the block using the following syntax, replacing `<ip>` with
    the actual IP that is blacklisted:
 
-    ```
-    del cache:gitlab:rack::attack:allow2ban:ban:<ip>
-    ```
+   ```
+   del cache:gitlab:rack::attack:allow2ban:ban:<ip>
+   ```
 
 1. Confirm that the key with the IP no longer shows up:
 
-    ```
-    keys *rack::attack*
-    ```
+   ```
+   keys *rack::attack*
+   ```
 
 1. Optionally, add the IP to the whitelist to prevent it from being blacklisted
    again (see [settings](#settings)).
@@ -136,8 +136,8 @@ the load balancer. In that case, you will need to:
 1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
 1. Reconfigure GitLab:
 
-    ```
-    sudo gitlab-ctl reconfigure
-    ```
+   ```
+   sudo gitlab-ctl reconfigure
+   ```
 
 1. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)

doc/ssh/README.md

@@ -64,13 +64,13 @@ Following [best practices](https://linux-audit.com/using-ed25519-openssh-keys-in
 you should always favor [ED25519](https://ed25519.cr.yp.to/) SSH keys, since they
 are more secure and have better performance over the other types.
 
-ED25519 SSH keys were introduced in OpenSSH 6.5, 
-so any modern OS should include the option to create them. 
-If for any reason your OS or the GitLab instance you interact with doesn't 
+ED25519 SSH keys were introduced in OpenSSH 6.5,
+so any modern OS should include the option to create them.
+If for any reason your OS or the GitLab instance you interact with doesn't
 support ED25519, you can fallback to RSA.
 
 NOTE: **Note:**
-Omnibus does not ship with OpenSSH, so it uses the version on your GitLab server. If using 
+Omnibus does not ship with OpenSSH, so it uses the version on your GitLab server. If using
 Omnibus, ensure the version of OpenSSH installed is version 6.5 or newer if you want to use ED25519 SSH keys.
 
 ### RSA SSH keys
@@ -107,18 +107,18 @@ To create a new SSH key pair:
 1. Open a terminal on Linux or macOS, or Git Bash / WSL on Windows.
 1. Generate a new ED25519 SSH key pair:
 
-    ```bash
-    ssh-keygen -t ed25519 -C "email@example.com"
-    ```
+   ```bash
+   ssh-keygen -t ed25519 -C "email@example.com"
+   ```
 
-    Or, if you want to use RSA:
+   Or, if you want to use RSA:
 
-    ```bash
-    ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
-    ```
+   ```bash
+   ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
+   ```
 
-    The `-C` flag adds a comment in the key in case you have multiple of them
-    and want to tell which is which. It is optional.
+   The `-C` flag adds a comment in the key in case you have multiple of them
+   and want to tell which is which. It is optional.
 
 1. Next, you will be prompted to input a file path to save your SSH key pair to.
    If you don't already have an SSH key pair and aren't generating a [deploy key](#deploy-keys),
@@ -126,21 +126,21 @@ To create a new SSH key pair:
    <kbd>Enter</kbd>. Using the suggested path will normally allow your SSH client
    to automatically use the SSH key pair with no additional configuration.
 
-    If you already have an SSH key pair with the suggested file path, you will need
-    to input a new file path and [declare what host](#working-with-non-default-ssh-key-pair-paths)
-    this SSH key pair will be used for in your `~/.ssh/config` file.
+   If you already have an SSH key pair with the suggested file path, you will need
+   to input a new file path and [declare what host](#working-with-non-default-ssh-key-pair-paths)
+   this SSH key pair will be used for in your `~/.ssh/config` file.
 
 1. Once the path is decided, you will be prompted to input a password to
    secure your new SSH key pair. It's a best practice to use a password,
    but it's not required and you can skip creating it by pressing
    <kbd>Enter</kbd> twice.
 
-    If, in any case, you want to add or change the password of your SSH key pair,
-    you can use the `-p` flag:
+   If, in any case, you want to add or change the password of your SSH key pair,
+   you can use the `-p` flag:
 
-    ```
-    ssh-keygen -p -o -f <keyname>
-    ```
+   ```
+   ssh-keygen -p -o -f <keyname>
+   ```
 
 Now, it's time to add the newly created public key to your GitLab account.
 
@@ -149,41 +149,40 @@ Now, it's time to add the newly created public key to your GitLab account.
 1. Copy your **public** SSH key to the clipboard by using one of the commands below
    depending on your Operating System:
 
-    **macOS:**
+   **macOS:**
 
-    ```bash
-    pbcopy < ~/.ssh/id_ed25519.pub
-    ```
+   ```bash
+   pbcopy < ~/.ssh/id_ed25519.pub
+   ```
 
-    **WSL / GNU/Linux (requires the xclip package):**
+   **WSL / GNU/Linux (requires the xclip package):**
 
-    ```bash
-    xclip -sel clip < ~/.ssh/id_ed25519.pub
-    ```
+   ```bash
+   xclip -sel clip < ~/.ssh/id_ed25519.pub
+   ```
 
-    **Git Bash on Windows:**
+   **Git Bash on Windows:**
 
-    ```bash
-    cat ~/.ssh/id_ed25519.pub | clip
-    ```
+   ```bash
+   cat ~/.ssh/id_ed25519.pub | clip
+   ```
 
-    You can also open the key in a graphical editor and copy it from there,
-    but be careful not to accidentally change anything.
+   You can also open the key in a graphical editor and copy it from there,
+   but be careful not to accidentally change anything.
 
-    NOTE: **Note:**
-    If you opted to create an RSA key, the name might differ.
+   NOTE: **Note:**
+   If you opted to create an RSA key, the name might differ.
 
 1. Add your **public** SSH key to your GitLab account by:
    1. Clicking your avatar in the upper right corner and selecting **Settings**.
    1. Navigating to **SSH Keys** and pasting your **public** key in the **Key** field. If you:
-
       - Created the key with a comment, this will appear in the **Title** field.
       - Created the key without a comment, give your key an identifiable title like _Work Laptop_ or _Home Workstation_.
    1. Click the **Add key** button.
 
-    NOTE: **Note:**
-    If you manually copied your public SSH key make sure you copied the entire
-    key starting with `ssh-ed25519` (or `ssh-rsa`) and ending with your email.
+   NOTE: **Note:**
+   If you manually copied your public SSH key make sure you copied the entire
+   key starting with `ssh-ed25519` (or `ssh-rsa`) and ending with your email.
 
 ## Testing that everything is set up correctly
 

doc/user/group/saml_sso/scim_setup.md

@@ -27,23 +27,23 @@ The following identity providers are supported:
 - [Group SSO](index.md) needs to be configured.
 - The `scim_group` feature flag must be enabled:
 
-    Run the following commands in a Rails console:
+  Run the following commands in a Rails console:
 
-    ```sh
-    # Omnibus GitLab
-    gitlab-rails console
+  ```sh
+  # Omnibus GitLab
+  gitlab-rails console
 
-    # Installation from source
-    cd /home/git/gitlab
-    sudo -u git -H bin/rails console RAILS_ENV=production
-    ```
+  # Installation from source
+  cd /home/git/gitlab
+  sudo -u git -H bin/rails console RAILS_ENV=production
+  ```
 
-    To enable SCIM for a group named `group_name`:
+  To enable SCIM for a group named `group_name`:
 
-    ```ruby
-    group = Group.find_by_full_path('group_name')
-    Feature.enable(:group_scim, group)
-    ```
+  ```ruby
+  group = Group.find_by_full_path('group_name')
+  Feature.enable(:group_scim, group)
+  ```
 
 ### GitLab configuration
 
@@ -85,26 +85,26 @@ You can then test the connection clicking on `Test Connection`.
 1. Map the `userPricipalName` to `emails[type eq "work"].value` and `mailNickname` to
    `userName`.
 
-    Example configuration:
+   Example configuration:
 
-    ![Azure's attribute mapping configuration](img/scim_attribute_mapping.png)
+   ![Azure's attribute mapping configuration](img/scim_attribute_mapping.png)
 
 1. Click on **Show advanced options > Edit attribute list for AppName**.
 1. Leave the `id` as the primary and only required field.
 
-    NOTE: **Note:**
-    `username` should neither be primary nor required as we don't support
-    that field on GitLab SCIM yet.
+   NOTE: **Note:**
+   `username` should neither be primary nor required as we don't support
+   that field on GitLab SCIM yet.
 
-    ![Azure's attribute advanced configuration](img/scim_advanced.png)
+   ![Azure's attribute advanced configuration](img/scim_advanced.png)
 
 1. Save all the screens and, in the **Provisioning** step, set
    the `Provisioning Status` to `ON`.
 
-    NOTE: **Note:**
-    You can control what is actually synced by selecting the `Scope`. For example,
-    `Sync only assigned users and groups` will only sync the users assigned to
-    the application (`Users and groups`), otherwise it will sync the whole Active Directory.
+   NOTE: **Note:**
+   You can control what is actually synced by selecting the `Scope`. For example,
+   `Sync only assigned users and groups` will only sync the users assigned to
+   the application (`Users and groups`), otherwise it will sync the whole Active Directory.
 
 Once enabled, the synchronization details and any errors will appear on the
 bottom of the **Provisioning** screen, together with a link to the audit logs.

doc/user/markdown.md

@@ -586,9 +586,11 @@ def function():
     print s
 ```
 
-    Using 4 spaces
-    is like using
-    3-backtick fences.
+```
+Using 4 spaces
+is like using
+3-backtick fences.
+```
 
 ~~~
 Tildes are OK too.

doc/user/profile/account/two_factor_authentication.md

@@ -183,29 +183,29 @@ a new set of recovery codes with SSH:
 1. You will then be prompted to confirm that you want to generate new codes.
    Continuing this process invalidates previously saved codes:
 
-    ```sh
-    Are you sure you want to generate new two-factor recovery codes?
-    Any existing recovery codes you saved will be invalidated. (yes/no)
-
-    yes
-
-    Your two-factor authentication recovery codes are:
-
-    119135e5a3ebce8e
-    11f6v2a498810dcd
-    3924c7ab2089c902
-    e79a3398bfe4f224
-    34bd7b74adbc8861
-    f061691d5107df1a
-    169bf32a18e63e7f
-    b510e7422e81c947
-    20dbed24c5e74663
-    df9d3b9403b9c9f0
-
-    During sign in, use one of the codes above when prompted for your
-    two-factor code. Then, visit your Profile Settings and add a new device
-    so you do not lose access to your account again.
-    ```
+   ```sh
+   Are you sure you want to generate new two-factor recovery codes?
+   Any existing recovery codes you saved will be invalidated. (yes/no)
+
+   yes
+
+   Your two-factor authentication recovery codes are:
+
+   119135e5a3ebce8e
+   11f6v2a498810dcd
+   3924c7ab2089c902
+   e79a3398bfe4f224
+   34bd7b74adbc8861
+   f061691d5107df1a
+   169bf32a18e63e7f
+   b510e7422e81c947
+   20dbed24c5e74663
+   df9d3b9403b9c9f0
+
+   During sign in, use one of the codes above when prompted for your
+   two-factor code. Then, visit your Profile Settings and add a new device
+   so you do not lose access to your account again.
+   ```
 
 1. Go to the GitLab sign-in page and enter your username/email and password.
    When prompted for a two-factor code, enter one of the recovery codes obtained

doc/user/project/clusters/eks_and_gitlab/index.md

@@ -40,97 +40,97 @@ then click **Add an existing Kubernetes cluster**.
 
 A few details from the EKS cluster will be required to connect it to GitLab:
 
-1.  **Retrieve the certificate**: A valid Kubernetes certificate is needed to
-    authenticate to the EKS cluster. We will use the certificate created by default.
-    Open a shell and use `kubectl` to retrieve it:
+1. **Retrieve the certificate**: A valid Kubernetes certificate is needed to
+   authenticate to the EKS cluster. We will use the certificate created by default.
+   Open a shell and use `kubectl` to retrieve it:
 
-    -  List the secrets with `kubectl get secrets`, and one should named similar to
-       `default-token-xxxxx`. Copy that token name for use below.
-    -  Get the certificate with:
+   - List the secrets with `kubectl get secrets`, and one should named similar to
+     `default-token-xxxxx`. Copy that token name for use below.
+   - Get the certificate with:
 
-       ```sh
-       kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
-       ```
-
-1.  **Create admin token**: A `cluster-admin` token is required to install and
-    manage Helm Tiller. GitLab establishes mutual SSL auth with Helm Tiller
-    and creates limited service accounts for each application. To create the
-    token we will create an admin service account as follows:
-
-    2.1. Create a file called `eks-admin-service-account.yaml` with contents:
-
-    ```yaml
-    apiVersion: v1
-    kind: ServiceAccount
-    metadata:
-      name: eks-admin
-      namespace: kube-system
-    ```
-
-    2.2. Apply the service account to your cluster:
-
-     ```bash
-    kubectl apply -f eks-admin-service-account.yaml
+     ```sh
+     kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
      ```
 
-    Output:
-
-    ```bash
-    serviceaccount "eks-admin" created
-    ```
-
-    2.3. Create a file called `eks-admin-cluster-role-binding.yaml` with contents:
-
-    ```yaml
-    apiVersion: rbac.authorization.k8s.io/v1beta1
-    kind: ClusterRoleBinding
-    metadata:
-      name: eks-admin
-    roleRef:
-      apiGroup: rbac.authorization.k8s.io
-      kind: ClusterRole
-      name: cluster-admin
-    subjects:
-    - kind: ServiceAccount
-      name: eks-admin
-      namespace: kube-system
-    ```
-
-    2.4. Apply the cluster role binding to your cluster:
-
-    ```bash
-    kubectl apply -f eks-admin-cluster-role-binding.yaml
-    ```
-
-    Output:
-
-    ```bash
-    clusterrolebinding "eks-admin" created
-    ```
-
-    2.5. Retrieve the token for the `eks-admin` service account:
-
-    ```bash
-    kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
-    ```
-
-    Copy the `<authentication_token>` value from the output:
-
-    ```yaml
-    Name:         eks-admin-token-b5zv4
-    Namespace:    kube-system
-    Labels:       <none>
-    Annotations:  kubernetes.io/service-account.name=eks-admin
-                  kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
-
-    Type:  kubernetes.io/service-account-token
-
-    Data
-    ====
-    ca.crt:     1025 bytes
-    namespace:  11 bytes
-    token:      <authentication_token>
-    ```
+1. **Create admin token**: A `cluster-admin` token is required to install and
+   manage Helm Tiller. GitLab establishes mutual SSL auth with Helm Tiller
+   and creates limited service accounts for each application. To create the
+   token we will create an admin service account as follows:
+
+   2.1. Create a file called `eks-admin-service-account.yaml` with contents:
+
+   ```yaml
+   apiVersion: v1
+   kind: ServiceAccount
+   metadata:
+     name: eks-admin
+     namespace: kube-system
+   ```
+
+   2.2. Apply the service account to your cluster:
+
+   ```bash
+   kubectl apply -f eks-admin-service-account.yaml
+   ```
+
+   Output:
+
+   ```bash
+   serviceaccount "eks-admin" created
+   ```
+
+   2.3. Create a file called `eks-admin-cluster-role-binding.yaml` with contents:
+
+   ```yaml
+   apiVersion: rbac.authorization.k8s.io/v1beta1
+   kind: ClusterRoleBinding
+   metadata:
+     name: eks-admin
+   roleRef:
+     apiGroup: rbac.authorization.k8s.io
+     kind: ClusterRole
+     name: cluster-admin
+   subjects:
+   - kind: ServiceAccount
+     name: eks-admin
+     namespace: kube-system
+   ```
+
+   2.4. Apply the cluster role binding to your cluster:
+
+   ```bash
+   kubectl apply -f eks-admin-cluster-role-binding.yaml
+   ```
+
+   Output:
+
+   ```bash
+   clusterrolebinding "eks-admin" created
+   ```
+
+   2.5. Retrieve the token for the `eks-admin` service account:
+
+   ```bash
+   kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
+   ```
+
+   Copy the `<authentication_token>` value from the output:
+
+   ```yaml
+   Name:         eks-admin-token-b5zv4
+   Namespace:    kube-system
+   Labels:       <none>
+   Annotations:  kubernetes.io/service-account.name=eks-admin
+                 kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
+
+   Type:  kubernetes.io/service-account-token
+
+   Data
+   ====
+   ca.crt:     1025 bytes
+   namespace:  11 bytes
+   token:      <authentication_token>
+   ```
 
 1. The API server endpoint is also required, so GitLab can connect to the cluster.
    This is displayed on the AWS EKS console, when viewing the EKS cluster details.

doc/user/project/clusters/index.md

@@ -56,8 +56,8 @@ new Kubernetes cluster to your project:
 
 1. Navigate to your project's **Operations > Kubernetes** page.
 
-    NOTE: **Note:**
-    You need Maintainer [permissions] and above to access the Kubernetes page.
+   NOTE: **Note:**
+   You need Maintainer [permissions] and above to access the Kubernetes page.
 
 1. Click **Add Kubernetes cluster**.
 1. Click **Create with Google Kubernetes Engine**.
@@ -97,117 +97,119 @@ To add an existing Kubernetes cluster to your project:
 
 1. Navigate to your project's **Operations > Kubernetes** page.
 
-    NOTE: **Note:**
-    You need Maintainer [permissions] and above to access the Kubernetes page.
+   NOTE: **Note:**
+   You need Maintainer [permissions] and above to access the Kubernetes page.
 
 1. Click **Add Kubernetes cluster**.
 1. Click **Add an existing Kubernetes cluster** and fill in the details:
-    - **Kubernetes cluster name** (required) - The name you wish to give the cluster.
-    - **Environment scope** (required) - The
-      [associated environment](#setting-the-environment-scope-premium) to this cluster.
-    - **API URL** (required) -
-      It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
-      exposes several APIs, we want the "base" URL that is common to all of them,
-      e.g., `https://kubernetes.example.com` rather than `https://kubernetes.example.com/api/v1`.
-
-      Get the API URL by running this command:
-
-      ```sh
-      kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'
-      ```
-    - **CA certificate** (required) - A valid Kubernetes certificate is needed to authenticate to the EKS cluster. We will use the certificate created by default.
-      - List the secrets with `kubectl get secrets`, and one should named similar to
-       `default-token-xxxxx`. Copy that token name for use below.
-      - Get the certificate by running this command:
-
-      ```sh
-      kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
-      ```
-    - **Token** -
-      GitLab authenticates against Kubernetes using service tokens, which are
-      scoped to a particular `namespace`.
-      **The token used should belong to a service account with
-      [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
-      privileges.** To create this service account:
-
-      1. Create a file called `gitlab-admin-service-account.yaml` with contents:
-
-         ```yaml
-         apiVersion: v1
-         kind: ServiceAccount
-         metadata:
-           name: gitlab-admin
-           namespace: kube-system
-         ---
-         apiVersion: rbac.authorization.k8s.io/v1beta1
-         kind: ClusterRoleBinding
-         metadata:
-           name: gitlab-admin
-         roleRef:
-           apiGroup: rbac.authorization.k8s.io
-           kind: ClusterRole
-           name: cluster-admin
-         subjects:
-         - kind: ServiceAccount
-           name: gitlab-admin
-           namespace: kube-system
-         ```
-
-      1. Apply the service account and cluster role binding to your cluster:
-
-          ```bash
-          kubectl apply -f gitlab-admin-service-account.yaml
-          ```
-
-          Output:
-
-          ```bash
-          serviceaccount "gitlab-admin" created
-          clusterrolebinding "gitlab-admin" created
-          ```
-
-      1. Retrieve the token for the `gitlab-admin` service account:
-
-          ```bash
-          kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
-          ```
-
-         Copy the `<authentication_token>` value from the output:
-
-         ```yaml
-         Name:         gitlab-admin-token-b5zv4
-         Namespace:    kube-system
-         Labels:       <none>
-         Annotations:  kubernetes.io/service-account.name=gitlab-admin
-                       kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
-
-         Type:  kubernetes.io/service-account-token
-
-         Data
-         ====
-         ca.crt:     1025 bytes
-         namespace:  11 bytes
-         token:      <authentication_token>
-         ```
-
-      NOTE: **Note:**
-      For GKE clusters, you will need the
-      `container.clusterRoleBindings.create` permission to create a cluster
-      role binding. You can follow the [Google Cloud
-      documentation](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
-      to grant access.
-
-    - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster. See the [Managed clusters section](#gitlab-managed-clusters) for more information.
-
-    - **Project namespace** (optional) - You don't have to fill it in; by leaving
-      it blank, GitLab will create one for you. Also:
-       - Each project should have a unique namespace.
-       - The project namespace is not necessarily the namespace of the secret, if
-         you're using a secret with broader permissions, like the secret from `default`.
-       - You should **not** use `default` as the project namespace.
-       - If you or someone created a secret specifically for the project, usually
-         with limited permissions, the secret's namespace and project namespace may
-         be the same.
+   - **Kubernetes cluster name** (required) - The name you wish to give the cluster.
+   - **Environment scope** (required) - The
+     [associated environment](#setting-the-environment-scope-premium) to this cluster.
+   - **API URL** (required) -
+     It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
+     exposes several APIs, we want the "base" URL that is common to all of them,
+     e.g., `https://kubernetes.example.com` rather than `https://kubernetes.example.com/api/v1`.
+
+     Get the API URL by running this command:
+
+     ```sh
+     kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'
+     ```
+
+   - **CA certificate** (required) - A valid Kubernetes certificate is needed to authenticate to the EKS cluster. We will use the certificate created by default.
+     - List the secrets with `kubectl get secrets`, and one should named similar to
+      `default-token-xxxxx`. Copy that token name for use below.
+     - Get the certificate by running this command:
+
+     ```sh
+     kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
+     ```
+
+   - **Token** -
+     GitLab authenticates against Kubernetes using service tokens, which are
+     scoped to a particular `namespace`.
+     **The token used should belong to a service account with
+     [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
+     privileges.** To create this service account:
+
+     1. Create a file called `gitlab-admin-service-account.yaml` with contents:
+
+        ```yaml
+        apiVersion: v1
+        kind: ServiceAccount
+        metadata:
+          name: gitlab-admin
+          namespace: kube-system
+        ---
+        apiVersion: rbac.authorization.k8s.io/v1beta1
+        kind: ClusterRoleBinding
+        metadata:
+          name: gitlab-admin
+        roleRef:
+          apiGroup: rbac.authorization.k8s.io
+          kind: ClusterRole
+          name: cluster-admin
+        subjects:
+        - kind: ServiceAccount
+          name: gitlab-admin
+          namespace: kube-system
+        ```
+
+     1. Apply the service account and cluster role binding to your cluster:
+
+        ```bash
+        kubectl apply -f gitlab-admin-service-account.yaml
+        ```
+
+        Output:
+
+        ```bash
+        serviceaccount "gitlab-admin" created
+        clusterrolebinding "gitlab-admin" created
+        ```
+
+     1. Retrieve the token for the `gitlab-admin` service account:
+
+        ```bash
+        kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
+        ```
+
+        Copy the `<authentication_token>` value from the output:
+
+        ```yaml
+        Name:         gitlab-admin-token-b5zv4
+        Namespace:    kube-system
+        Labels:       <none>
+        Annotations:  kubernetes.io/service-account.name=gitlab-admin
+                      kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
+
+        Type:  kubernetes.io/service-account-token
+
+        Data
+        ====
+        ca.crt:     1025 bytes
+        namespace:  11 bytes
+        token:      <authentication_token>
+        ```
+
+     NOTE: **Note:**
+     For GKE clusters, you will need the
+     `container.clusterRoleBindings.create` permission to create a cluster
+     role binding. You can follow the [Google Cloud
+     documentation](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
+     to grant access.
+
+   - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster. See the [Managed clusters section](#gitlab-managed-clusters) for more information.
+
+   - **Project namespace** (optional) - You don't have to fill it in; by leaving
+     it blank, GitLab will create one for you. Also:
+     - Each project should have a unique namespace.
+     - The project namespace is not necessarily the namespace of the secret, if
+       you're using a secret with broader permissions, like the secret from `default`.
+     - You should **not** use `default` as the project namespace.
+     - If you or someone created a secret specifically for the project, usually
+       with limited permissions, the secret's namespace and project namespace may
+       be the same.
 
 1. Finally, click the **Create Kubernetes cluster** button.
 

doc/user/project/container_registry.md

@@ -241,10 +241,10 @@ The following installation instructions assume you are running Ubuntu:
    Enter <kbd>CTRL</kbd>-<kbd>C</kbd> to quit.
 1. Install the certificate from `~/.mitmproxy` to your system:
 
-    ```sh
-    sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
-    sudo update-ca-certificates
-    ```
+   ```sh
+   sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
+   sudo update-ca-certificates
+   ```
 
 If successful, the output should indicate that a certificate was added:
 

doc/user/project/deploy_boards.md

@@ -63,12 +63,12 @@ To display the Deploy Boards for a specific [environment] you should:
 
 1. Have a Kubernetes cluster up and running.
 
-    NOTE: **Running on OpenShift:**
-    If you are using OpenShift, ensure that you're using the `Deployment` resource
-    instead of `DeploymentConfiguration`, otherwise the Deploy Boards won't render
-    correctly. For more information, read the
-    [OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
-    and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab-ee/issues/4584).
+   NOTE: **Running on OpenShift:**
+   If you are using OpenShift, ensure that you're using the `Deployment` resource
+   instead of `DeploymentConfiguration`, otherwise the Deploy Boards won't render
+   correctly. For more information, read the
+   [OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
+   and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab-ee/issues/4584).
 
 1. [Configure GitLab Runner][runners] with the [Docker][docker-exec] or
    [Kubernetes][kube-exec] executor.
@@ -93,7 +93,7 @@ To display the Deploy Boards for a specific [environment] you should:
    To migrate, please apply the required annotations (see above) and
    re-deploy your application.
 
-    ![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
+   ![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
 
 Once all of the above are set up and the pipeline has run at least once,
 navigate to the environments page under **Operations > Environments**.

doc/user/project/deploy_tokens/index.md

@@ -56,9 +56,9 @@ To download a repository using a Deploy Token, you just need to:
 1. Take note of your `username` and `token`.
 1. `git clone` the project using the Deploy Token:
 
-    ```sh
-    git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
-    ```
+   ```sh
+   git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
+   ```
 
 Replace `<username>` and `<deploy_token>` with the proper values.
 

doc/user/project/integrations/prometheus_library/kubernetes.md

@@ -13,15 +13,15 @@ integration services must be enabled.
 
 - Average Memory Usage (MB):
 
-    ```
-    avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
-    ```
+  ```
+  avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
+  ```
 
 - Average CPU Utilization (%):
 
-    ```
-    avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
-    ```
+  ```
+  avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
+  ```
 
 ## Configuring Prometheus to monitor for Kubernetes metrics
 
@@ -48,12 +48,12 @@ These metrics expect the [Deployment](https://kubernetes.io/docs/concepts/worklo
 
 - Average Memory Usage (MB)
 
-    ```
-    avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
-    ```
+  ```
+  avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
+  ```
 
 - Average CPU Utilization (%)
 
-    ```
-    avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
-    ```
+  ```
+  avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
+  ```

doc/user/project/packages/maven_repository.md

@@ -198,7 +198,7 @@ domain name.
 NOTE: **Note:**
 For retrieving artifacts, you can use either the
 [URL encoded](../../../api/README.md#namespaced-path-encoding) path of the group
-(e.g., `group%2Fsubgroup`) or the group's ID (e.g., `12`). 
+(e.g., `group%2Fsubgroup`) or the group's ID (e.g., `12`).
 
 ### Instance level Maven endpoint
 
@@ -279,59 +279,59 @@ shows how to create a new package each time the `master` branch is updated:
    Add the server section with the same id you defined in your `pom.xml` file.
    For example, in our case it's `gitlab-maven`:
 
-    ```xml
-    <settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
-      <servers>
-        <server>
-          <id>gitlab-maven</id>
-          <configuration>
-            <httpHeaders>
-              <property>
-                <name>Job-Token</name>
-                <value>${env.CI_JOB_TOKEN}</value>
-              </property>
-            </httpHeaders>
-          </configuration>
-        </server>
-      </servers>
-    </settings>
-    ```
+   ```xml
+   <settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
+     <servers>
+       <server>
+         <id>gitlab-maven</id>
+         <configuration>
+           <httpHeaders>
+             <property>
+               <name>Job-Token</name>
+               <value>${env.CI_JOB_TOKEN}</value>
+             </property>
+           </httpHeaders>
+         </configuration>
+       </server>
+     </servers>
+   </settings>
+   ```
 
 1. Make sure your `pom.xml` file includes the following:
 
-    ```xml
-    <repositories>
-      <repository>
-        <id>gitlab-maven</id>
-        <url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
-      </repository>
-    </repositories>
-    <distributionManagement>
-      <repository>
-        <id>gitlab-maven</id>
-        <url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
-      </repository>
-      <snapshotRepository>
-        <id>gitlab-maven</id>
-        <url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
-      </snapshotRepository>
-    </distributionManagement>
-    ```
-
-    TIP: **Tip:**
-    You can either let Maven utilize the CI environment variables or hardcode your project's ID.
+   ```xml
+   <repositories>
+     <repository>
+       <id>gitlab-maven</id>
+       <url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
+     </repository>
+   </repositories>
+   <distributionManagement>
+     <repository>
+       <id>gitlab-maven</id>
+       <url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
+     </repository>
+     <snapshotRepository>
+       <id>gitlab-maven</id>
+       <url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
+     </snapshotRepository>
+   </distributionManagement>
+   ```
+
+   TIP: **Tip:**
+   You can either let Maven utilize the CI environment variables or hardcode your project's ID.
 
 1. Add a `deploy` job to your `.gitlab-ci.yml` file:
 
-    ```yaml
-    deploy:
-      image: maven:3.3.9-jdk-8
-      script:
-        - 'mvn deploy -s ci_settings.xml'
-      only:
-        - master
-    ```
+   ```yaml
+   deploy:
+     image: maven:3.3.9-jdk-8
+     script:
+       - 'mvn deploy -s ci_settings.xml'
+     only:
+       - master
+   ```
 
 1. Push those files to your repository.
 

doc/user/project/pages/lets_encrypt_for_gitlab_pages.md

@@ -36,111 +36,111 @@ operating systems the steps might be slightly different. Follow the
 [CertBot instructions](https://certbot.eff.org/) according to your OS.
 
 1. On your computer, open a terminal and navigate to your repository's
-  root directory:
+   root directory:
 
-    ```bash
-    cd path/to/dir
-    ```
+   ```bash
+   cd path/to/dir
+   ```
 
 1. Install CertBot (the tool Let's Encrypt uses to issue certificates):
 
-    ```bash
-    brew install certbot
-    ```
+   ```bash
+   brew install certbot
+   ```
 
 1. Request a certificate for your domain (`example.com`) and
-  provide an email account (`your@email.com`) to receive notifications:
+   provide an email account (`your@email.com`) to receive notifications:
 
-    ```bash
-    sudo certbot certonly -a manual -d example.com --email your@email.com
-    ```
+   ```bash
+   sudo certbot certonly -a manual -d example.com --email your@email.com
+   ```
 
-    Alternatively, you can register without adding an e-mail account,
-    but you won't be notified about the certificate expiration's date:
+   Alternatively, you can register without adding an e-mail account,
+   but you won't be notified about the certificate expiration's date:
 
-    ```bash
-    sudo certbot certonly -a manual -d example.com --register-unsafely-without-email
-    ```
+   ```bash
+   sudo certbot certonly -a manual -d example.com --register-unsafely-without-email
+   ```
 
-    TIP: **Tip:**
-    Read through CertBot's documentation on their
-    [command line options](https://certbot.eff.org/docs/using.html#certbot-command-line-options).
+   TIP: **Tip:**
+   Read through CertBot's documentation on their
+   [command line options](https://certbot.eff.org/docs/using.html#certbot-command-line-options).
 
 1. You'll be prompted with a message to agree with their terms.
-  Press `A` to agree and `Y` to let they log your IP.
+   Press `A` to agree and `Y` to let they log your IP.
 
-    CertBot will then prompt you with the following message:
+   CertBot will then prompt you with the following message:
 
-    ```bash
-    Create a file containing just this data:
+   ```bash
+   Create a file containing just this data:
 
-    Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
+   Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
 
-    And make it available on your web server at this URL:
+   And make it available on your web server at this URL:
 
-    http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP
+   http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP
 
-    Press Enter to Continue
-    ```
+   Press Enter to Continue
+   ```
 
 1. **Do not press Enter yet.** Let's Encrypt will need to verify your
-  domain ownership before issuing the certificate. To do so, create 3
-  consecutive directories under your website's root:
-  `/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP/`
-  and add to the last folder an `index.html` file containing the content
-  referred on the previous prompt message:
-
-    ```bash
-    Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
-    ```
-
-    Note that this file needs to be accessed under
-    `http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP`
-    to allow Let's Encrypt to verify the ownership of your domain,
-    therefore, it needs to be part of the website content under the
-    repo's [`public`](index.md#how-it-works) folder.
+   domain ownership before issuing the certificate. To do so, create 3
+   consecutive directories under your website's root:
+   `/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP/`
+   and add to the last folder an `index.html` file containing the content
+   referred on the previous prompt message:
+
+   ```bash
+   Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
+   ```
+
+   Note that this file needs to be accessed under
+   `http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP`
+   to allow Let's Encrypt to verify the ownership of your domain,
+   therefore, it needs to be part of the website content under the
+   repo's [`public`](index.md#how-it-works) folder.
 
 1. Add, commit, and push the file into your repo in GitLab. Once the pipeline
-  passes, press **Enter** on your terminal to continue issuing your
-  certificate. CertBot will then prompt you with the following message:
-
-    ```bash
-    Waiting for verification...
-    Cleaning up challenges
-
-    IMPORTANT NOTES:
-     - Congratulations! Your certificate and chain have been saved at:
-       /etc/letsencrypt/live/example.com/fullchain.pem
-       Your key file has been saved at:
-       /etc/letsencrypt/live/example.com/privkey.pem
-       Your cert will expire on 2019-03-12. To obtain a new or tweaked
-       version of this certificate in the future, simply run certbot
-       again. To non-interactively renew *all* of your certificates, run
-       "certbot renew"
-     - If you like Certbot, please consider supporting our work by:
-
-       Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
-       Donating to EFF:                    https://eff.org/donate-le
-    ```
+   passes, press **Enter** on your terminal to continue issuing your
+   certificate. CertBot will then prompt you with the following message:
+
+   ```bash
+   Waiting for verification...
+   Cleaning up challenges
+
+   IMPORTANT NOTES:
+    - Congratulations! Your certificate and chain have been saved at:
+      /etc/letsencrypt/live/example.com/fullchain.pem
+      Your key file has been saved at:
+      /etc/letsencrypt/live/example.com/privkey.pem
+      Your cert will expire on 2019-03-12. To obtain a new or tweaked
+      version of this certificate in the future, simply run certbot
+      again. To non-interactively renew *all* of your certificates, run
+      "certbot renew"
+    - If you like Certbot, please consider supporting our work by:
+
+      Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
+      Donating to EFF:                    https://eff.org/donate-le
+   ```
 
 ## Add your certificate to GitLab Pages
 
 Now that your certificate has been issued, let's add it to your Pages site:
 
 1. Back at GitLab, navigate to your project's **Settings > Pages**,
-  find your domain and click **Details** and **Edit** to add your certificate.
+   find your domain and click **Details** and **Edit** to add your certificate.
 1. From your terminal, copy and paste the certificate into the first field
-  **Certificate (PEM)**:
+   **Certificate (PEM)**:
 
-    ```bash
-    sudo cat /etc/letsencrypt/live/example.com/fullchain.pem | pbcopy
-    ```
+   ```bash
+   sudo cat /etc/letsencrypt/live/example.com/fullchain.pem | pbcopy
+   ```
 
 1. Copy and paste the private key into the second field **Key (PEM)**:
 
-    ```bash
-    sudo cat /etc/letsencrypt/live/example.com/privkey.pem | pbcopy
-    ```
+   ```bash
+   sudo cat /etc/letsencrypt/live/example.com/privkey.pem | pbcopy
+   ```
 
 1. Click **Save changes** to apply them to your website.
 1. Wait a few minutes for the configuration changes to take effect.

doc/user/project/repository/gpg_signed_commits/index.md

@@ -45,94 +45,95 @@ started:
 1. Generate the private/public key pair with the following command, which will
    spawn a series of questions:
 
-    ```sh
-    gpg --full-gen-key
-    ```
+   ```sh
+   gpg --full-gen-key
+   ```
 
-    NOTE: **Note:**
-    In some cases like Gpg4win on Windows and other macOS versions, the command
-    here may be `gpg --gen-key`.
+   NOTE: **Note:**
+   In some cases like Gpg4win on Windows and other macOS versions, the command
+   here may be `gpg --gen-key`.
 
 1. The first question is which algorithm can be used.  Select the kind you want
    or press <kbd>Enter</kbd> to choose the default (RSA and RSA):
 
-    ```
-    Please select what kind of key you want:
-       (1) RSA and RSA (default)
-       (2) DSA and Elgamal
-       (3) DSA (sign only)
-       (4) RSA (sign only)
-    Your selection? 1
-    ```
+   ```
+   Please select what kind of key you want:
+      (1) RSA and RSA (default)
+      (2) DSA and Elgamal
+      (3) DSA (sign only)
+      (4) RSA (sign only)
+   Your selection? 1
+   ```
 
 1. The next question is key length. We recommend to choose the highest value
    which is `4096`:
 
-    ```
-    RSA keys may be between 1024 and 4096 bits long.
-    What keysize do you want? (2048) 4096
-    Requested keysize is 4096 bits
-    ```
+   ```
+   RSA keys may be between 1024 and 4096 bits long.
+   What keysize do you want? (2048) 4096
+   Requested keysize is 4096 bits
+   ```
+
 1. Next, you need to specify the validity period of your key. This is something
    subjective, and you can use the default value which is to never expire:
 
-    ```
-    Please specify how long the key should be valid.
-             0 = key does not expire
-          <n>  = key expires in n days
-          <n>w = key expires in n weeks
-          <n>m = key expires in n months
-          <n>y = key expires in n years
-    Key is valid for? (0) 0
-    Key does not expire at all
-    ```
+   ```
+   Please specify how long the key should be valid.
+            0 = key does not expire
+         <n>  = key expires in n days
+         <n>w = key expires in n weeks
+         <n>m = key expires in n months
+         <n>y = key expires in n years
+   Key is valid for? (0) 0
+   Key does not expire at all
+   ```
 
 1. Confirm that the answers you gave were correct by typing `y`:
 
-    ```
-    Is this correct? (y/N) y
-    ```
+   ```
+   Is this correct? (y/N) y
+   ```
 
 1. Enter you real name, the email address to be associated with this key (should
    match a verified email address you use in GitLab) and an optional comment
    (press <kbd>Enter</kbd> to skip):
 
-    ```
-    GnuPG needs to construct a user ID to identify your key.
+   ```
+   GnuPG needs to construct a user ID to identify your key.
 
-    Real name: Mr. Robot
-    Email address: <your_email>
-    Comment:
-    You selected this USER-ID:
-        "Mr. Robot <your_email>"
+   Real name: Mr. Robot
+   Email address: <your_email>
+   Comment:
+   You selected this USER-ID:
+       "Mr. Robot <your_email>"
 
-    Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
-    ```
+   Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
+   ```
 
 1. Pick a strong password when asked and type it twice to confirm.
 1. Use the following command to list the private GPG key you just created:
 
-    ```
-    gpg --list-secret-keys --keyid-format LONG <your_email>
-    ```
+   ```
+   gpg --list-secret-keys --keyid-format LONG <your_email>
+   ```
 
-    Replace `<your_email>` with the email address you entered above.
+   Replace `<your_email>` with the email address you entered above.
 
 1. Copy the GPG key ID that starts with `sec`. In the following example, that's
    `30F2B65B9246B6CA`:
 
-    ```
-    sec   rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
-          D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
-    uid                   [ultimate] Mr. Robot <your_email>
-    ssb   rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
-    ```
+   ```
+   sec   rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
+         D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
+   uid                   [ultimate] Mr. Robot <your_email>
+   ssb   rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
+   ```
 
 1. Export the public key of that ID (replace your key ID from the previous step):
 
-    ```
-    gpg --armor --export 30F2B65B9246B6CA
-    ```
+   ```
+   gpg --armor --export 30F2B65B9246B6CA
+   ```
 
 1. Finally, copy the public key and [add it in your profile settings](#adding-a-gpg-key-to-your-account)
 
@@ -146,17 +147,17 @@ You can add a GPG key in your profile's settings:
 
 1. On the upper right corner, click on your avatar and go to your **Settings**.
 
-    ![Settings dropdown](../../../profile/img/profile_settings_dropdown.png)
+   ![Settings dropdown](../../../profile/img/profile_settings_dropdown.png)
 
 1. Navigate to the **GPG keys** tab and paste your _public_ key in the 'Key'
    box.
 
-    ![Paste GPG public key](img/profile_settings_gpg_keys_paste_pub.png)
+   ![Paste GPG public key](img/profile_settings_gpg_keys_paste_pub.png)
 
 1. Finally, click on **Add key** to add it to GitLab. You will be able to see
    its fingerprint, the corresponding email address and creation date.
 
-    ![GPG key single page](img/profile_settings_gpg_keys_single_key.png)
+   ![GPG key single page](img/profile_settings_gpg_keys_single_key.png)
 
 ## Associating your GPG key with Git
 
@@ -166,29 +167,29 @@ key to use.
 
 1. Use the following command to list the private GPG key you just created:
 
-    ```sh
-    gpg --list-secret-keys --keyid-format LONG <your_email>
-    ```
+   ```sh
+   gpg --list-secret-keys --keyid-format LONG <your_email>
+   ```
 
-    Replace `<your_email>` with the email address you entered above.
+   Replace `<your_email>` with the email address you entered above.
 
 1. Copy the GPG key ID that starts with `sec`. In the following example, that's
    `30F2B65B9246B6CA`:
 
-    ```
-    sec   rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
-          D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
-    uid                   [ultimate] Mr. Robot <your_email>
-    ssb   rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
-    ```
+   ```
+   sec   rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
+         D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
+   uid                   [ultimate] Mr. Robot <your_email>
+   ssb   rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
+   ```
 
 1. Tell Git to use that key to sign the commits:
 
-    ```sh
-    git config --global user.signingkey 30F2B65B9246B6CA
-    ```
+   ```sh
+   git config --global user.signingkey 30F2B65B9246B6CA
+   ```
 
-    Replace `30F2B65B9246B6CA` with your GPG key ID.
+   Replace `30F2B65B9246B6CA` with your GPG key ID.
 
 1. (Optional) If Git is using `gpg` and you get errors like `secret key not available`
    or `gpg: signing failed: secret key not available`, run the following command to
@@ -206,9 +207,9 @@ commits:
 
 1. Commit like you used to, the only difference is the addition of the `-S` flag:
 
-    ```
-    git commit -S -m "My commit msg"
-    ```
+   ```
+   git commit -S -m "My commit msg"
+   ```
 
 1. Enter the passphrase of your GPG key when asked.
 1. Push to GitLab and check that your commits [are verified](#verifying-commits).
@@ -227,13 +228,13 @@ git config --global commit.gpgsign true
    "Verified" or "Unverified", depending on the verification status of the GPG
    signature.
 
-    ![Signed and unsigned commits](img/project_signed_and_unsigned_commits.png)
+   ![Signed and unsigned commits](img/project_signed_and_unsigned_commits.png)
 
 1. By clicking on the GPG badge, details of the signature are displayed.
 
-    ![Signed commit with verified signature](img/project_signed_commit_verified_signature.png)
+   ![Signed commit with verified signature](img/project_signed_commit_verified_signature.png)
 
-    ![Signed commit with verified signature](img/project_signed_commit_unverified_signature.png)
+   ![Signed commit with verified signature](img/project_signed_commit_unverified_signature.png)
 
 ## Revoking a GPG key
 

doc/user/project/repository/reducing_the_repo_size_using_git.md

@@ -54,50 +54,50 @@ removed from the repository.
 
 1. Navigate to your repository:
 
-    ```
-    cd my_repository/
-    ```
+   ```
+   cd my_repository/
+   ```
 
 1. Change to the branch you want to remove the big file from:
 
-    ```
-    git checkout master
-    ```
+   ```
+   git checkout master
+   ```
 
 1. Create a commit removing the large file from the branch, if it still exists:
 
-    ```
-    git rm path/to/big_file.mpg
-    git commit -m 'Remove unneeded large file'
-    ```
+   ```
+   git rm path/to/big_file.mpg
+   git commit -m 'Remove unneeded large file'
+   ```
 
 1. Rewrite history:
 
-    ```
-    bfg --delete-files path/to/big_file.mpg
-    ```
+   ```
+   bfg --delete-files path/to/big_file.mpg
+   ```
 
-    An object map file will be written to `object-id-map.old-new.txt`. Keep it
-    around - you'll need it for the final step!
+   An object map file will be written to `object-id-map.old-new.txt`. Keep it
+   around - you'll need it for the final step!
 
 1. Force-push the changes to GitLab:
 
-    ```
-    git push --force-with-lease origin master
-    ```
+   ```
+   git push --force-with-lease origin master
+   ```
 
-    If this step fails, someone has changed the `master` branch while you were
-    rewriting history. You could restore the branch and re-run BFG to preserve
-    their changes, or use `git push --force` to overwrite their changes.
+   If this step fails, someone has changed the `master` branch while you were
+   rewriting history. You could restore the branch and re-run BFG to preserve
+   their changes, or use `git push --force` to overwrite their changes.
 
 1. Navigate to **Project > Settings > Repository > Repository Cleanup**:
 
-    ![Repository settings cleanup form](img/repository_cleanup.png)
+   ![Repository settings cleanup form](img/repository_cleanup.png)
 
-    Upload the `object-id-map.old-new.txt` file and press **Start cleanup**.
-    This will remove any internal git references to the old commits, and run
-    `git gc` against the repository. You will receive an email once it has
-    completed.
+   Upload the `object-id-map.old-new.txt` file and press **Start cleanup**.
+   This will remove any internal git references to the old commits, and run
+   `git gc` against the repository. You will receive an email once it has
+   completed.
 
 NOTE: **Note:**
 This process will remove some copies of the rewritten commits from GitLab's
@@ -110,32 +110,32 @@ purposes!
 
 1. Navigate to your repository:
 
-    ```
-    cd my_repository/
-    ```
+   ```
+   cd my_repository/
+   ```
 
 1. Change to the branch you want to remove the big file from:
 
-    ```
-    git checkout master
-    ```
+   ```
+   git checkout master
+   ```
 
 1. Use `filter-branch` to remove the big file:
 
-    ```
-    git filter-branch --force --tree-filter 'rm -f path/to/big_file.mpg' HEAD
-    ```
+   ```
+   git filter-branch --force --tree-filter 'rm -f path/to/big_file.mpg' HEAD
+   ```
 
 1. Instruct Git to purge the unwanted data:
 
-    ```
-    git reflog expire --expire=now --all && git gc --prune=now --aggressive
-    ```
+   ```
+   git reflog expire --expire=now --all && git gc --prune=now --aggressive
+   ```
 
 1. Lastly, force push to the repository:
 
-    ```
-    git push --force origin master
-    ```
+   ```
+   git push --force origin master
+   ```
 
 Your repository should now be below the size limit.