Use consistent spacing with yaml arrays in docs

doc/administration/monitoring/prometheus/index.md

@@ -165,54 +165,54 @@ To use an external Prometheus server:
 
    ```yaml
    scrape_configs:
-   - job_name: nginx
-     static_configs:
-     - targets:
-       - 1.1.1.1:8060
-   - job_name: redis
-     static_configs:
-     - targets:
-       - 1.1.1.1:9121
-   - job_name: postgres
-     static_configs:
-     - targets:
-       - 1.1.1.1:9187
-   - job_name: node
-     static_configs:
-     - targets:
-       - 1.1.1.1:9100
-   - job_name: gitlab-workhorse
-     static_configs:
-     - targets:
-       - 1.1.1.1:9229
-   - job_name: gitlab-rails
-     metrics_path: "/-/metrics"
-     static_configs:
-     - targets:
-       - 1.1.1.1:8080
-   - job_name: gitlab-sidekiq
-     static_configs:
-     - targets:
-       - 1.1.1.1:8082
-   - job_name: gitlab_exporter_database
-     metrics_path: "/database"
-     static_configs:
-     - targets:
-       - 1.1.1.1:9168
-   - job_name: gitlab_exporter_sidekiq
-     metrics_path: "/sidekiq"
-     static_configs:
-     - targets:
-       - 1.1.1.1:9168
-   - job_name: gitlab_exporter_process
-     metrics_path: "/process"
-     static_configs:
-     - targets:
-       - 1.1.1.1:9168
-   - job_name: gitaly
-     static_configs:
-     - targets:
-       - 1.1.1.1:9236
+     - job_name: nginx
+       static_configs:
+         - targets:
+           - 1.1.1.1:8060
+     - job_name: redis
+       static_configs:
+         - targets:
+           - 1.1.1.1:9121
+     - job_name: postgres
+       static_configs:
+         - targets:
+           - 1.1.1.1:9187
+     - job_name: node
+       static_configs:
+         - targets:
+           - 1.1.1.1:9100
+     - job_name: gitlab-workhorse
+       static_configs:
+         - targets:
+           - 1.1.1.1:9229
+     - job_name: gitlab-rails
+       metrics_path: "/-/metrics"
+       static_configs:
+         - targets:
+           - 1.1.1.1:8080
+     - job_name: gitlab-sidekiq
+       static_configs:
+         - targets:
+           - 1.1.1.1:8082
+     - job_name: gitlab_exporter_database
+       metrics_path: "/database"
+       static_configs:
+         - targets:
+           - 1.1.1.1:9168
+     - job_name: gitlab_exporter_sidekiq
+       metrics_path: "/sidekiq"
+       static_configs:
+         - targets:
+           - 1.1.1.1:9168
+     - job_name: gitlab_exporter_process
+       metrics_path: "/process"
+       static_configs:
+         - targets:
+           - 1.1.1.1:9168
+     - job_name: gitaly
+       static_configs:
+         - targets:
+           - 1.1.1.1:9236
    ```
 
 1. Reload the Prometheus server.

doc/ci/caching/index.md

@@ -226,14 +226,14 @@ image: node:latest
 cache:
   key: ${CI_COMMIT_REF_SLUG}
   paths:
-  - .npm/
+    - .npm/
 
 before_script:
   - npm ci --cache .npm --prefer-offline
 
 test_async:
   script:
-  - node ./specs/start.js ./specs/async.spec.js
+    - node ./specs/start.js ./specs/async.spec.js
 ```
 
 ### Caching PHP dependencies
@@ -253,16 +253,16 @@ image: php:7.2
 cache:
   key: ${CI_COMMIT_REF_SLUG}
   paths:
-  - vendor/
+    - vendor/
 
 before_script:
-# Install and run Composer
-- curl --show-error --silent https://getcomposer.org/installer | php
-- php composer.phar install
+  # Install and run Composer
+  - curl --show-error --silent https://getcomposer.org/installer | php
+  - php composer.phar install
 
 test:
   script:
-  - vendor/bin/phpunit --configuration phpunit.xml --coverage-text --colors=never
+    - vendor/bin/phpunit --configuration phpunit.xml --coverage-text --colors=never
 ```
 
 ### Caching Python dependencies
@@ -301,9 +301,9 @@ before_script:
 
 test:
   script:
-  - python setup.py test
-  - pip install flake8
-  - flake8 .
+    - python setup.py test
+    - pip install flake8
+    - flake8 .
 ```
 
 ### Caching Ruby dependencies
@@ -330,7 +330,7 @@ before_script:
 
 rspec:
   script:
-  - rspec spec
+    - rspec spec
 ```
 
 ### Caching Go dependencies
@@ -354,7 +354,7 @@ test:
   image: golang:1.13
   extends: .go-cache
   script:
-  - go test ./... -v -short
+    - go test ./... -v -short
 ```
 
 ## Availability of the cache
@@ -391,28 +391,28 @@ stages:
 
 ```yaml
 stages:
-- build
-- test
+  - build
+  - test
 
 before_script:
-- echo "Hello"
+  - echo "Hello"
 
 job A:
   stage: build
   script:
-  - mkdir vendor/
-  - echo "build" > vendor/hello.txt
+    - mkdir vendor/
+    - echo "build" > vendor/hello.txt
   cache:
     key: build-cache
     paths:
-    - vendor/
+      - vendor/
   after_script:
-  - echo "World"
+    - echo "World"
 
 job B:
   stage: test
   script:
-  - cat vendor/hello.txt
+    - cat vendor/hello.txt
   cache:
     key: build-cache
 ```
@@ -483,8 +483,8 @@ cache when the pipeline is run for a second time.
 
 ```yaml
 stages:
-- build
-- test
+  - build
+  - test
 
 job A:
   stage: build
@@ -492,7 +492,7 @@ job A:
   cache:
     key: same-key
     paths:
-    - public/
+      - public/
 
 job B:
   stage: test
@@ -500,7 +500,7 @@ job B:
   cache:
     key: same-key
     paths:
-    - vendor/
+      - vendor/
 ```
 
 1. `job A` runs.
@@ -520,8 +520,8 @@ will be different):
 
 ```yaml
 stages:
-- build
-- test
+  - build
+  - test
 
 job A:
   stage: build
@@ -529,7 +529,7 @@ job A:
   cache:
     key: keyA
     paths:
-    - vendor/
+      - vendor/
 
 job B:
   stage: test
@@ -537,7 +537,7 @@ job B:
   cache:
     key: keyB
     paths:
-    - vendor/
+      - vendor/
 ```
 
 In that case, even if the `key` is different (no fear of overwriting), you

doc/ci/docker/using_docker_images.md

@@ -149,14 +149,14 @@ the job will fail:
 ```yaml
 job:
   services:
-  - php:7
-  - node:latest
-  - golang:1.10
+    - php:7
+    - node:latest
+    - golang:1.10
   image: alpine:3.7
   script:
-  - php -v
-  - node -v
-  - go version
+    - php -v
+    - node -v
+    - go version
 ```
 
 If you need to have `php`, `node` and `go` available for your script, you should
@@ -176,7 +176,7 @@ You can then use for example the [tutum/wordpress](https://hub.docker.com/r/tutu
 
 ```yaml
 services:
-- tutum/wordpress:latest
+  - tutum/wordpress:latest
 ```
 
 If you don't [specify a service alias](#available-settings-for-services),
@@ -219,7 +219,7 @@ default:
 
 test:
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 The image name must be in one of the following formats:
@@ -238,16 +238,16 @@ default:
 test:2.6:
   image: ruby:2.6
   services:
-  - postgres:11.7
+    - postgres:11.7
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 
 test:2.7:
   image: ruby:2.7
   services:
-  - postgres:12.2
+    - postgres:12.2
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 Or you can pass some [extended configuration options](#extended-docker-configuration-options)
@@ -260,17 +260,17 @@ default:
     entrypoint: ["/bin/bash"]
 
   services:
-  - name: my-postgres:11.7
-    alias: db-postgres
-    entrypoint: ["/usr/local/bin/db-postgres"]
-    command: ["start"]
+    - name: my-postgres:11.7
+      alias: db-postgres
+      entrypoint: ["/usr/local/bin/db-postgres"]
+      command: ["start"]
 
   before_script:
-  - bundle install
+    - bundle install
 
 test:
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 ## Passing environment variables to services
@@ -292,21 +292,21 @@ variables:
   POSTGRES_INITDB_ARGS: "--encoding=UTF8 --data-checksums"
 
 services:
-- name: postgres:11.7
-  alias: db
-  entrypoint: ["docker-entrypoint.sh"]
-  command: ["postgres"]
+  - name: postgres:11.7
+    alias: db
+    entrypoint: ["docker-entrypoint.sh"]
+    command: ["postgres"]
 
 image:
   name: ruby:2.6
   entrypoint: ["/bin/bash"]
 
 before_script:
-- bundle install
+  - bundle install
 
 test:
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 ## Extended Docker configuration options
@@ -330,8 +330,8 @@ For example, the following two definitions are equal:
    image: "registry.example.com/my/image:latest"
 
    services:
-   - postgresql:9.4
-   - redis:latest
+     - postgresql:9.4
+     - redis:latest
    ```
 
 1. Using a map as an option to `image` and `services`. The use of `image:name` is
@@ -342,8 +342,8 @@ For example, the following two definitions are equal:
      name: "registry.example.com/my/image:latest"
 
    services:
-   - name: postgresql:9.4
-   - name: redis:latest
+     - name: postgresql:9.4
+     - name: redis:latest
    ```
 
 ### Available settings for `image`
@@ -378,8 +378,8 @@ would not work properly:
 
 ```yaml
 services:
-- mysql:latest
-- mysql:latest
+  - mysql:latest
+  - mysql:latest
 ```
 
 The Runner would start two containers using the `mysql:latest` image, but both
@@ -392,10 +392,10 @@ look like:
 
 ```yaml
 services:
-- name: mysql:latest
-  alias: mysql-1
-- name: mysql:latest
-  alias: mysql-2
+  - name: mysql:latest
+    alias: mysql-1
+  - name: mysql:latest
+    alias: mysql-2
 ```
 
 The Runner will still start two containers using the `mysql:latest` image,
@@ -427,7 +427,7 @@ CMD ["/usr/bin/super-sql", "run"]
 # .gitlab-ci.yml
 
 services:
-- my-super-sql:latest
+  - my-super-sql:latest
 ```
 
 After the new extended Docker configuration options, you can now simply
@@ -437,8 +437,8 @@ set a `command` in `.gitlab-ci.yml`, like:
 # .gitlab-ci.yml
 
 services:
-- name: super/sql:latest
-  command: ["/usr/bin/super-sql", "run"]
+  - name: super/sql:latest
+    command: ["/usr/bin/super-sql", "run"]
 ```
 
 As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`](https://docs.docker.com/engine/reference/builder/#cmd).

doc/ci/environments/index.md

@@ -94,7 +94,7 @@ deploy_staging:
     name: staging
     url: https://staging.example.com
   only:
-  - master
+    - master
 ```
 
 We have defined three [stages](../yaml/README.md#stages):
@@ -259,7 +259,7 @@ deploy_staging:
     name: staging
     url: https://staging.example.com
   only:
-  - master
+    - master
 
 deploy_prod:
   stage: deploy
@@ -270,7 +270,7 @@ deploy_prod:
     url: https://example.com
   when: manual
   only:
-  - master
+    - master
 ```
 
 The `when: manual` action:
@@ -407,7 +407,7 @@ deploy:
     kubernetes:
       namespace: production
   only:
-  - master
+    - master
 ```
 
 When deploying to a Kubernetes cluster using GitLab's Kubernetes integration,
@@ -483,7 +483,7 @@ deploy_staging:
     name: staging
     url: https://staging.example.com
   only:
-  - master
+    - master
 
 deploy_prod:
   stage: deploy
@@ -494,7 +494,7 @@ deploy_prod:
     url: https://example.com
   when: manual
   only:
-  - master
+    - master
 ```
 
 A more realistic example would also include copying files to a location where a

doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md

@@ -61,10 +61,10 @@ content:
 ```yaml
 ---
 applications:
-- name: gitlab-hello-world
-  random-route: true
-  memory: 1G
-  path: target/demo-0.0.1-SNAPSHOT.jar
+  - name: gitlab-hello-world
+    random-route: true
+    memory: 1G
+    path: target/demo-0.0.1-SNAPSHOT.jar
 ```
 
 ## Configure GitLab CI/CD to deploy your application
@@ -96,11 +96,11 @@ build:
 production:
   stage: deploy
   script:
-  - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
-  - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
-  - ./cf push
+    - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
+    - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
+    - ./cf push
   only:
-  - master
+    - master
 ```
 
 We've used the `java:8` [Docker

doc/ci/examples/deployment/README.md

@@ -45,8 +45,8 @@ All possible parameters can be found here: <https://github.com/travis-ci/dpl#her
 staging:
   stage: deploy
   script:
-  - gem install dpl
-  - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
 ```
 
 In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
@@ -64,12 +64,12 @@ You will have to install it:
 staging:
   stage: deploy
   script:
-  - apt-get update -yq
-  - apt-get install -y ruby-dev
-  - gem install dpl
-  - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
+    - apt-get update -yq
+    - apt-get install -y ruby-dev
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
   only:
-  - master
+    - master
 ```
 
 The first line `apt-get update -yq` updates the list of available packages,
@@ -89,18 +89,18 @@ The final `.gitlab-ci.yml` for that setup would look like this:
 staging:
   stage: deploy
   script:
-  - gem install dpl
-  - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
   only:
-  - master
+    - master
 
 production:
   stage: deploy
   script:
-  - gem install dpl
-  - dpl --provider=heroku --app=my-app-production --api-key=$HEROKU_PRODUCTION_API_KEY
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-production --api-key=$HEROKU_PRODUCTION_API_KEY
   only:
-  - tags
+    - tags
 ```
 
 We created two deploy jobs that are executed on different events:

doc/ci/examples/deployment/composer-npm-deploy.md

@@ -150,7 +150,7 @@ before_script:
 stage_deploy:
   artifacts:
     paths:
-    - build/
+      - build/
   only:
     - dev
   script:

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -274,19 +274,19 @@ just pack them up in the cache. Here is the full `build` job:
 
 ```yaml
 build:
-    stage: build
-    script:
-        - npm i gulp -g
-        - npm i
-        - gulp
-        - gulp build-test
-    cache:
-        policy: push
-        paths:
-        - node_modules
-    artifacts:
-        paths:
-        - built
+  stage: build
+  script:
+    - npm i gulp -g
+    - npm i
+    - gulp
+    - gulp build-test
+  cache:
+    policy: push
+    paths:
+      - node_modules
+  artifacts:
+    paths:
+      - built
 ```
 
 ### Test your game with GitLab CI/CD
@@ -301,18 +301,18 @@ Following the YAML structure, the `test` job should look like this:
 
 ```yaml
 test:
-    stage: test
-    script:
-        - npm i gulp -g
-        - npm i
-        - gulp run-test
-    cache:
-        policy: push
-        paths:
-        - node_modules/
-    artifacts:
-        paths:
-        - built/
+  stage: test
+  script:
+    - npm i gulp -g
+    - npm i
+    - gulp run-test
+  cache:
+    policy: push
+    paths:
+      - node_modules/
+  artifacts:
+    paths:
+      - built/
 ```
 
 We have added unit tests for a `Weapon` class that shoots on a specified interval.
@@ -325,33 +325,33 @@ Our entire `.gitlab-ci.yml` file should now look like this:
 image: node:10
 
 build:
-    stage: build
-    script:
-        - npm i gulp -g
-        - npm i
-        - gulp
-        - gulp build-test
-    cache:
-        policy: push
-        paths:
-        - node_modules/
-    artifacts:
-        paths:
-        - built/
+  stage: build
+  script:
+    - npm i gulp -g
+    - npm i
+    - gulp
+    - gulp build-test
+  cache:
+    policy: push
+    paths:
+      - node_modules/
+  artifacts:
+    paths:
+      - built/
 
 test:
-    stage: test
-    script:
-        - npm i gulp -g
-        - npm i
-        - gulp run-test
-    cache:
-        policy: pull
-        paths:
-        - node_modules/
-    artifacts:
-        paths:
-        - built/
+  stage: test
+  script:
+    - npm i gulp -g
+    - npm i
+    - gulp run-test
+  cache:
+    policy: pull
+    paths:
+      - node_modules/
+  artifacts:
+    paths:
+      - built/
 ```
 
 ### Run your CI/CD pipeline
@@ -445,18 +445,18 @@ trigger the `deploy` job of our pipeline. Put these together to get the followin
 
 ```yaml
 deploy:
-    stage: deploy
-    variables:
-        AWS_ACCESS_KEY_ID: "$AWS_KEY_ID"
-        AWS_SECRET_ACCESS_KEY: "$AWS_KEY_SECRET"
-    script:
-        - apt-get update
-        - apt-get install -y python3-dev python3-pip
-        - easy_install3 -U pip
-        - pip3 install --upgrade awscli
-        - aws s3 sync ./built s3://gitlab-game-demo --region "us-east-1" --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers --cache-control "no-cache, no-store, must-revalidate" --delete
-    only:
-        - master
+  stage: deploy
+  variables:
+    AWS_ACCESS_KEY_ID: "$AWS_KEY_ID"
+    AWS_SECRET_ACCESS_KEY: "$AWS_KEY_SECRET"
+  script:
+    - apt-get update
+    - apt-get install -y python3-dev python3-pip
+    - easy_install3 -U pip
+    - pip3 install --upgrade awscli
+    - aws s3 sync ./built s3://gitlab-game-demo --region "us-east-1" --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers --cache-control "no-cache, no-store, must-revalidate" --delete
+  only:
+    - master
 ```
 
 Be sure to update the region and S3 URL in that last script command to fit your setup.
@@ -466,46 +466,46 @@ Our final configuration file `.gitlab-ci.yml` looks like:
 image: node:10
 
 build:
-    stage: build
-    script:
-        - npm i gulp -g
-        - npm i
-        - gulp
-        - gulp build-test
-    cache:
-        policy: push
-        paths:
-        - node_modules/
-    artifacts:
-        paths:
-        - built/
+  stage: build
+  script:
+    - npm i gulp -g
+    - npm i
+    - gulp
+    - gulp build-test
+  cache:
+    policy: push
+    paths:
+      - node_modules/
+  artifacts:
+    paths:
+      - built/
 
 test:
-    stage: test
-    script:
-        - npm i gulp -g
-        - gulp run-test
-    cache:
-        policy: pull
-        paths:
-        - node_modules/
-    artifacts:
-        paths:
-        - built/
+  stage: test
+  script:
+    - npm i gulp -g
+    - gulp run-test
+  cache:
+    policy: pull
+    paths:
+      - node_modules/
+  artifacts:
+    paths:
+      - built/
 
 deploy:
-    stage: deploy
-    variables:
-        AWS_ACCESS_KEY_ID: "$AWS_KEY_ID"
-        AWS_SECRET_ACCESS_KEY: "$AWS_KEY_SECRET"
-    script:
-        - apt-get update
-        - apt-get install -y python3-dev python3-pip
-        - easy_install3 -U pip
-        - pip3 install --upgrade awscli
-        - aws s3 sync ./built s3://gitlab-game-demo --region "us-east-1" --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers --cache-control "no-cache, no-store, must-revalidate" --delete
-    only:
-        - master
+  stage: deploy
+  variables:
+    AWS_ACCESS_KEY_ID: "$AWS_KEY_ID"
+    AWS_SECRET_ACCESS_KEY: "$AWS_KEY_SECRET"
+  script:
+    - apt-get update
+    - apt-get install -y python3-dev python3-pip
+    - easy_install3 -U pip
+    - pip3 install --upgrade awscli
+    - aws s3 sync ./built s3://gitlab-game-demo --region "us-east-1" --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers --cache-control "no-cache, no-store, must-revalidate" --delete
+  only:
+    - master
 ```
 
 ## Conclusion

doc/ci/examples/php.md

@@ -76,7 +76,7 @@ environment, let's add it in `.gitlab-ci.yml`:
 ...
 
 before_script:
-- bash ci/docker_install.sh > /dev/null
+  - bash ci/docker_install.sh > /dev/null
 
 ...
 ```
@@ -88,7 +88,7 @@ Last step, run the actual tests using `phpunit`:
 
 test:app:
   script:
-  - phpunit --configuration phpunit_myapp.xml
+    - phpunit --configuration phpunit_myapp.xml
 
 ...
 ```
@@ -104,11 +104,11 @@ image: php:5.6
 
 before_script:
 # Install dependencies
-- bash ci/docker_install.sh > /dev/null
+  - bash ci/docker_install.sh > /dev/null
 
 test:app:
   script:
-  - phpunit --configuration phpunit_myapp.xml
+    - phpunit --configuration phpunit_myapp.xml
 ```
 
 ### Test against different PHP versions in Docker builds
@@ -119,19 +119,19 @@ with a different Docker image version and the runner will do the rest:
 ```yaml
 before_script:
 # Install dependencies
-- bash ci/docker_install.sh > /dev/null
+  - bash ci/docker_install.sh > /dev/null
 
 # We test PHP5.6
 test:5.6:
   image: php:5.6
   script:
-  - phpunit --configuration phpunit_myapp.xml
+    - phpunit --configuration phpunit_myapp.xml
 
 # We test PHP7.0 (good luck with that)
 test:7.0:
   image: php:7.0
   script:
-  - phpunit --configuration phpunit_myapp.xml
+    - phpunit --configuration phpunit_myapp.xml
 ```
 
 ### Custom PHP configuration in Docker builds
@@ -142,7 +142,7 @@ add a `before_script` action:
 
 ```yaml
 before_script:
-- cp my_php.ini /usr/local/etc/php/conf.d/test.ini
+  - cp my_php.ini /usr/local/etc/php/conf.d/test.ini
 ```
 
 Of course, `my_php.ini` must be present in the root directory of your repository.
@@ -166,7 +166,7 @@ Next, add the following snippet to your `.gitlab-ci.yml`:
 ```yaml
 test:app:
   script:
-  - phpunit --configuration phpunit_myapp.xml
+    - phpunit --configuration phpunit_myapp.xml
 ```
 
 Finally, push to GitLab and let the tests begin!
@@ -217,11 +217,11 @@ you can use [atoum](https://github.com/atoum/atoum):
 
 ```yaml
 before_script:
-- wget http://downloads.atoum.org/nightly/mageekguy.atoum.phar
+  - wget http://downloads.atoum.org/nightly/mageekguy.atoum.phar
 
 test:atoum:
   script:
-  - php mageekguy.atoum.phar
+    - php mageekguy.atoum.phar
 ```
 
 ### Using Composer
@@ -238,16 +238,16 @@ following in your `.gitlab-ci.yml`:
 # your git repository.
 cache:
   paths:
-  - vendor/
+    - vendor/
 
 before_script:
 # Install composer dependencies
-- wget https://composer.github.io/installer.sig -O - -q | tr -d '\n' > installer.sig
-- php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
-- php -r "if (hash_file('SHA384', 'composer-setup.php') === file_get_contents('installer.sig')) { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
-- php composer-setup.php
-- php -r "unlink('composer-setup.php'); unlink('installer.sig');"
-- php composer.phar install
+  - wget https://composer.github.io/installer.sig -O - -q | tr -d '\n' > installer.sig
+  - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
+  - php -r "if (hash_file('SHA384', 'composer-setup.php') === file_get_contents('installer.sig')) { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
+  - php composer-setup.php
+  - php -r "unlink('composer-setup.php'); unlink('installer.sig');"
+  - php composer.phar install
 
 ...
 ```

doc/ci/examples/test-and-deploy-python-application-to-heroku.md

@@ -23,32 +23,32 @@ stages:
 test:
   stage: test
   script:
-  # this configures Django application to use attached postgres database that is run on `postgres` host
-  - export DATABASE_URL=postgres://postgres:@postgres:5432/python-test-app
-  - apt-get update -qy
-  - apt-get install -y python-dev python-pip
-  - pip install -r requirements.txt
-  - python manage.py test
+    # this configures Django application to use attached postgres database that is run on `postgres` host
+    - export DATABASE_URL=postgres://postgres:@postgres:5432/python-test-app
+    - apt-get update -qy
+    - apt-get install -y python-dev python-pip
+    - pip install -r requirements.txt
+    - python manage.py test
 
 staging:
   stage: deploy
   script:
-  - apt-get update -qy
-  - apt-get install -y ruby-dev
-  - gem install dpl
-  - dpl --provider=heroku --app=gitlab-ci-python-test-staging --api-key=$HEROKU_STAGING_API_KEY
+    - apt-get update -qy
+    - apt-get install -y ruby-dev
+    - gem install dpl
+    - dpl --provider=heroku --app=gitlab-ci-python-test-staging --api-key=$HEROKU_STAGING_API_KEY
   only:
-  - master
+    - master
 
 production:
   stage: deploy
   script:
-  - apt-get update -qy
-  - apt-get install -y ruby-dev
-  - gem install dpl
-  - dpl --provider=heroku --app=gitlab-ci-python-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY
+    - apt-get update -qy
+    - apt-get install -y ruby-dev
+    - gem install dpl
+    - dpl --provider=heroku --app=gitlab-ci-python-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY
   only:
-  - tags
+    - tags
 ```
 
 This project has three jobs:

doc/ci/jenkins/index.md

@@ -181,8 +181,8 @@ pdf:
   script: xelatex mycv.tex
   artifacts:
     paths:
-    - ./mycv.pdf
-    - ./output/
+      - ./mycv.pdf
+      - ./output/
     expire_in: 1 week
 ```
 

doc/ci/merge_request_pipelines/index.md

@@ -65,19 +65,19 @@ build:
   stage: build
   script: ./build
   only:
-  - master
+    - master
 
 test:
   stage: test
   script: ./test
   only:
-  - merge_requests
+    - merge_requests
 
 deploy:
   stage: deploy
   script: ./deploy
   only:
-  - master
+    - master
 ```
 
 #### Excluding certain jobs

doc/ci/migration/circleci.md

@@ -250,14 +250,14 @@ image: node:latest
 cache:
   key: $CI_COMMIT_REF_SLUG
   paths:
-  - .npm/
+    - .npm/
 
 before_script:
   - npm ci --cache .npm --prefer-offline
 
 test_async:
   script:
-  - node ./specs/start.js ./specs/async.spec.js
+    - node ./specs/start.js ./specs/async.spec.js
 ```
 
 ## Contexts and variables

doc/ci/pipelines/index.md

@@ -348,17 +348,17 @@ For example, these three jobs will be in a group named `build ruby`:
 build ruby 1/3:
   stage: build
   script:
-  - echo "ruby1"
+    - echo "ruby1"
 
 build ruby 2/3:
   stage: build
   script:
-  - echo "ruby2"
+    - echo "ruby2"
 
 build ruby 3/3:
   stage: build
   script:
-  - echo "ruby3"
+    - echo "ruby3"
 ```
 
 In the pipeline, the result is a group named `build ruby` with three jobs:

doc/ci/pipelines/job_artifacts.md

@@ -33,7 +33,7 @@ pdf:
   script: xelatex mycv.tex
   artifacts:
     paths:
-    - mycv.pdf
+      - mycv.pdf
     expire_in: 1 week
 ```
 
@@ -87,8 +87,8 @@ Below is an example of collecting a JUnit XML file from Ruby's RSpec test tool:
 rspec:
   stage: test
   script:
-  - bundle install
-  - rspec --format RspecJunitFormatter --out rspec.xml
+    - bundle install
+    - rspec --format RspecJunitFormatter --out rspec.xml
   artifacts:
     reports:
       junit: rspec.xml

doc/ci/triggers/README.md

@@ -62,9 +62,9 @@ and it creates a dependent pipeline relation visible on the
 build_docs:
   stage: deploy
   script:
-  - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline
+    - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline
   only:
-  - tags
+    - tags
 ```
 
 Pipelines triggered that way also expose a special variable:
@@ -86,11 +86,11 @@ build_submodule:
   image: debian
   stage: test
   script:
-  - apt update && apt install -y unzip
-  - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test&job_token=$CI_JOB_TOKEN"
-  - unzip artifacts.zip
+    - apt update && apt install -y unzip
+    - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test&job_token=$CI_JOB_TOKEN"
+    - unzip artifacts.zip
   only:
-  - tags
+    - tags
 ```
 
 This allows you to use that for multi-project pipelines and download artifacts
@@ -179,9 +179,9 @@ need to add in project A's `.gitlab-ci.yml`:
 build_docs:
   stage: deploy
   script:
-  - "curl --request POST --form token=TOKEN --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+    - "curl --request POST --form token=TOKEN --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
   only:
-  - tags
+    - tags
 ```
 
 This means that whenever a new tag is pushed on project A, the job will run and the
@@ -235,24 +235,24 @@ variable is non-zero, `make upload` is run.
 
 ```yaml
 stages:
-- test
-- build
-- package
+  - test
+  - build
+  - package
 
 run_tests:
   stage: test
   script:
-  - make test
+    - make test
 
 build_package:
   stage: build
   script:
-  - make build
+    - make build
 
 upload_package:
   stage: package
   script:
-  - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi
+    - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi
 ```
 
 You can then trigger a rebuild while you pass the `UPLOAD_TO_S3` variable

doc/ci/yaml/README.md

@@ -3743,9 +3743,9 @@ Combining the individual examples given above for `release`, we'd have the follo
 
 ```yaml
 stages:
-- build
-- test
-- release-stg
+  - build
+  - test
+  - release-stg
 
 release_job:
   stage: release
@@ -4331,11 +4331,11 @@ Example:
 
 ```yaml
 .something_before: &something_before
-- echo 'something before'
+  - echo 'something before'
 
 .something_after: &something_after
-- echo 'something after'
-- echo 'another thing after'
+  - echo 'something after'
+  - echo 'another thing after'
 
 job_name:
   before_script:
@@ -4357,7 +4357,7 @@ For example:
 
 ```yaml
 .something: &something
-- echo 'something'
+  - echo 'something'
 
 job_name:
   script:

doc/development/documentation/site_architecture/index.md

@@ -152,9 +152,9 @@ Suppose we have the `content/_data/versions.yaml` file with the content:
 
 ```yaml
 versions:
-- 10.6
-- 10.5
-- 10.4
+  - 10.6
+  - 10.5
+  - 10.4
 ```
 
 We can then loop over the `versions` array with something like:

doc/development/prometheus_metrics.md

@@ -11,16 +11,16 @@ The requirement for adding a new metric is to make each query to have an unique
 ```yaml
 - group: Response metrics (NGINX Ingress)
   metrics:
-  - title: "Throughput"
-    y_axis:
-      name: "Requests / Sec"
-      format: "number"
-      precision: 2
-    queries:
-    - id: response_metrics_nginx_ingress_throughput_status_code
-      query_range: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code)'
-      unit: req / sec
-      label: Status Code
+    - title: "Throughput"
+      y_axis:
+        name: "Requests / Sec"
+        format: "number"
+        precision: 2
+      queries:
+        - id: response_metrics_nginx_ingress_throughput_status_code
+          query_range: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code)'
+          unit: req / sec
+          label: Status Code
 ```
 
 ### Update existing metrics

doc/topics/autodevops/customize.md

@@ -445,7 +445,7 @@ QA testing:
   environment:
     name: qa
   script:
-  - deploy foo
+    - deploy foo
 ```
 
 The track `foo` being referenced must also be defined in the application's Helm chart, like:

doc/topics/autodevops/stages.md

@@ -469,16 +469,16 @@ workers:
   sidekiq:
     replicaCount: 1
     command:
-    - /bin/herokuish
-    - procfile
-    - exec
-    - sidekiq
+      - /bin/herokuish
+      - procfile
+      - exec
+      - sidekiq
     preStopCommand:
-    - /bin/herokuish
-    - procfile
-    - exec
-    - sidekiqctl
-    - quiet
+      - /bin/herokuish
+      - procfile
+      - exec
+      - sidekiqctl
+      - quiet
     terminationGracePeriodSeconds: 60
 ```
 
@@ -524,12 +524,12 @@ networkPolicy:
       matchLabels:
         app.gitlab.com/env: staging
     ingress:
-    - from:
-      - podSelector:
-          matchLabels: {}
-      - namespaceSelector:
-          matchLabels:
-            app.gitlab.com/managed_by: gitlab
+      - from:
+        - podSelector:
+            matchLabels: {}
+        - namespaceSelector:
+            matchLabels:
+              app.gitlab.com/managed_by: gitlab
 ```
 
 For more information on installing Network Policies, see

doc/user/clusters/crossplane.md

@@ -55,18 +55,18 @@ export REGION=us-central1 # the GCP region where the GKE cluster is provisioned.
         labels:
           rbac.authorization.k8s.io/aggregate-to-edit: "true"
       rules:
-      - apiGroups:
-        - database.crossplane.io
-        resources:
-        - postgresqlinstances
-        verbs:
-        - get
-        - list
-        - create
-        - update
-        - delete
-        - patch
-        - watch
+        - apiGroups:
+            - database.crossplane.io
+          resources:
+            - postgresqlinstances
+          verbs:
+            - get
+            - list
+            - create
+            - update
+            - delete
+            - patch
+            - watch
       ```
 
   1. Apply the cluster role to the cluster:

doc/user/clusters/management_project.md

@@ -97,7 +97,7 @@ Development, Staging, and Production cluster respectively.
 
 ```yaml
 stages:
-- deploy
+  - deploy
 
 configure development cluster:
   stage: deploy

doc/user/gitlab_com/index.md

@@ -337,9 +337,9 @@ Windows Shared Runners:
 ```yaml
 .shared_windows_runners:
   tags:
-  - shared-windows
-  - windows
-  - windows-1809
+    - shared-windows
+    - windows
+    - windows-1809
 
 stages:
   - build
@@ -352,17 +352,17 @@ before_script:
 
 build:
   extends:
-  - .shared_windows_runners
+    - .shared_windows_runners
   stage: build
   script:
-  - echo "running scripts in the build job"
+    - echo "running scripts in the build job"
 
 test:
   extends:
-  - .shared_windows_runners
+    - .shared_windows_runners
   stage: test
   script:
-  - echo "running scripts in the test job"
+    - echo "running scripts in the test job"
 ```
 
 #### Limitations and known issues

doc/user/group/clusters/index.md

@@ -127,8 +127,8 @@ And the following environments are set in [`.gitlab-ci.yml`](../../../ci/yaml/RE
 
 ```yaml
 stages:
-- test
-- deploy
+  - test
+  - deploy
 
 test:
   stage: test

doc/user/project/clusters/add_remove_clusters.md

@@ -227,9 +227,9 @@ To add a Kubernetes cluster to your project, group, or instance:
            kind: ClusterRole
            name: cluster-admin
          subjects:
-         - kind: ServiceAccount
-           name: gitlab-admin
-           namespace: kube-system
+           - kind: ServiceAccount
+             name: gitlab-admin
+             namespace: kube-system
          ```
 
       1. Apply the service account and cluster role binding to your cluster:

doc/user/project/clusters/index.md

@@ -99,8 +99,8 @@ And the following environments are set in
 
 ```yaml
 stages:
-- test
-- deploy
+  - test
+  - deploy
 
 test:
   stage: test

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

@@ -392,29 +392,19 @@ want to store your package:
 image: python:latest
 
 stages:
-
   - deploy
 
 production:
-
   stage: deploy
-
   before_script:
-
     - pip3 install awscli --upgrade
-
     - pip3 install aws-sam-cli --upgrade
-
   script:
-
     - sam build
-
     - sam package --output-template-file packaged.yaml --s3-bucket <S3_bucket_name>
-
     - sam deploy --template-file packaged.yaml --stack-name gitlabpoc  --s3-bucket <S3_bucket_name> --capabilities CAPABILITY_IAM --region us-east-1
-
   environment: production
-  ```
+```
 
 Let’s examine the configuration file more closely:
 

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

@@ -143,24 +143,24 @@ You must do the following:
        labels:
          rbac.authorization.k8s.io/aggregate-to-edit: "true"
      rules:
-     - apiGroups:
-       - serving.knative.dev
-       resources:
-       - configurations
-       - configurationgenerations
-       - routes
-       - revisions
-       - revisionuids
-       - autoscalers
-       - services
-       verbs:
-       - get
-       - list
-       - create
-       - update
-       - delete
-       - patch
-       - watch
+       - apiGroups:
+           - serving.knative.dev
+         resources:
+           - configurations
+           - configurationgenerations
+           - routes
+           - revisions
+           - revisionuids
+           - autoscalers
+           - services
+         verbs:
+           - get
+           - list
+           - create
+           - update
+           - delete
+           - patch
+           - watch
      ```
 
      Then run the following command:

doc/user/project/integrations/prometheus.md

@@ -290,17 +290,17 @@ For example:
    panel_groups:
      - group: 'Group Title'
        panels:
-       - type: area-chart
-         title: "Chart Title"
-         y_label: "Y-Axis"
-         y_axis:
-           format: number
-           precision: 0
-         metrics:
-         - id: my_metric_id
-           query_range: 'http_requests_total'
-           label: "Instance: {{instance}}, method: {{method}}"
-           unit: "count"
+         - type: area-chart
+           title: "Chart Title"
+           y_label: "Y-Axis"
+           y_axis:
+             format: number
+             precision: 0
+           metrics:
+             - id: my_metric_id
+               query_range: 'http_requests_total'
+               label: "Instance: {{instance}}, method: {{method}}"
+               unit: "count"
    ```
 
    The above sample dashboard would display a single area chart. Each file should
@@ -641,25 +641,24 @@ To add a stacked column panel type to a dashboard, look at the following sample
 dashboard: 'Dashboard title'
 priority: 1
 panel_groups:
-- group: 'Group Title'
-  priority: 5
-  panels:
-  - type: 'stacked-column'
-    title: "Stacked column"
-    y_label: "y label"
-    x_label: 'x label'
-    metrics:
-      - id: memory_1
-        query_range: 'memory_query'
-        label: "memory query 1"
-        unit: "count"
-        series_name: 'group 1'
-      - id: memory_2
-        query_range: 'memory_query_2'
-        label: "memory query 2"
-        unit: "count"
-        series_name: 'group 2'
-
+  - group: 'Group Title'
+    priority: 5
+    panels:
+      - type: 'stacked-column'
+        title: "Stacked column"
+        y_label: "y label"
+        x_label: 'x label'
+        metrics:
+          - id: memory_1
+            query_range: 'memory_query'
+            label: "memory query 1"
+            unit: "count"
+            series_name: 'group 1'
+          - id: memory_2
+            query_range: 'memory_query_2'
+            label: "memory query 2"
+            unit: "count"
+            series_name: 'group 2'
 ```
 
 ![stacked column panel type](img/prometheus_dashboard_stacked_column_panel_type_v12_8.png)
@@ -681,10 +680,10 @@ panel_groups:
       - title: "Single Stat"
         type: "single-stat"
         metrics:
-        - id: 10
-          query: 'max(go_memstats_alloc_bytes{job="prometheus"})'
-          unit: MB
-          label: "Total"
+          - id: 10
+            query: 'max(go_memstats_alloc_bytes{job="prometheus"})'
+            unit: MB
+            label: "Total"
 ```
 
 Note the following properties:
@@ -711,10 +710,10 @@ panel_groups:
         type: "single-stat"
         max_value: 100
         metrics:
-        - id: 10
-          query: 'max(go_memstats_alloc_bytes{job="prometheus"})'
-          unit: '%'
-          label: "Total"
+          - id: 10
+            query: 'max(go_memstats_alloc_bytes{job="prometheus"})'
+            unit: '%'
+            label: "Total"
 ```
 
 For example, if you have a query value of `53.6`, adding `%` as the unit results in a single stat value of `53.6%`, but if the maximum expected value of the query is `120`, the value would be `44.6%`. Adding the `max_value` causes the correct percentage value to display.
@@ -733,10 +732,10 @@ panel_groups:
       - title: "Heatmap"
         type: "heatmap"
         metrics:
-        - id: 10
-          query: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[60m])) by (status_code)'
-          unit: req/sec
-          label: "Status code"
+          - id: 10
+            query: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[60m])) by (status_code)'
+            unit: req/sec
+            label: "Status code"
 ```
 
 Note the following properties:
@@ -846,11 +845,11 @@ templating:
       type: custom
       options:
         values:
-        - value: 'value option 1'        # The value that will replace the variable in queries.
-          text: 'Option 1'               # (Optional) Text that will appear in the UI dropdown.
-        - value: 'value_option_2'
-          text: 'Option 2'
-          default: true                  # (Optional) This option should be the default value of this variable.
+          - value: 'value option 1'        # The value that will replace the variable in queries.
+            text: 'Option 1'               # (Optional) Text that will appear in the UI dropdown.
+          - value: 'value_option_2'
+            text: 'Option 2'
+            default: true                  # (Optional) This option should be the default value of this variable.
 ```
 
 ##### `metric_label_values` variable type
@@ -1030,10 +1029,10 @@ To send GitLab alert notifications, copy the *URL* and *Authorization Key* into
 receivers:
   name: gitlab
   webhook_configs:
-  - http_config:
-      bearer_token: 9e1cbfcd546896a9ea8be557caf13a76
-    send_resolved: true
-    url: http://192.168.178.31:3001/root/manual_prometheus/prometheus/alerts/notify.json
+    - http_config:
+        bearer_token: 9e1cbfcd546896a9ea8be557caf13a76
+      send_resolved: true
+      url: http://192.168.178.31:3001/root/manual_prometheus/prometheus/alerts/notify.json
   ...
 ```
 

doc/user/project/pages/getting_started/pages_from_scratch.md

@@ -101,9 +101,9 @@ with GitLab Pages:
 ```yaml
 pages:
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build
 ```
 
 ## Specify the `public` directory for output
@@ -116,9 +116,9 @@ Jekyll uses destination (`-d`) to specify an output directory for the built webs
 ```yaml
 pages:
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
 ```
 
 ## Specify the `public` directory for artifacts
@@ -130,12 +130,12 @@ in the `public` directory:
 ```yaml
 pages:
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
 ```
 
 Paste this into `.gitlab-ci.yml` file, so it now looks like this:
@@ -145,12 +145,12 @@ image: ruby:2.7
 
 pages:
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
 ```
 
 Now save and commit the `.gitlab-ci.yml` file. You can watch the pipeline run
@@ -181,12 +181,12 @@ workflow:
 
 pages:
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
 ```
 
 Then configure the pipeline to run the job for the master branch only.
@@ -200,12 +200,12 @@ workflow:
 
 pages:
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
   rules:
     - if: '$CI_COMMIT_BRANCH == "master"'
 ```
@@ -232,12 +232,12 @@ workflow:
 pages:
   stage: deploy
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
   rules:
     - if: '$CI_COMMIT_BRANCH == "master"'
 ```
@@ -255,24 +255,24 @@ workflow:
 pages:
   stage: deploy
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d public
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
   rules:
     - if: '$CI_COMMIT_BRANCH == "master"'
 
 test:
   stage: test
   script:
-  - gem install bundler
-  - bundle install
-  - bundle exec jekyll build -d test
+    - gem install bundler
+    - bundle install
+    - bundle exec jekyll build -d test
   artifacts:
     paths:
-    - test
+      - test
   rules:
     - if: '$CI_COMMIT_BRANCH != "master"'
 ```
@@ -310,20 +310,20 @@ before_script:
 pages:
   stage: deploy
   script:
-  - bundle exec jekyll build -d public
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
   rules:
     - if: '$CI_COMMIT_BRANCH == "master"'
 
 test:
   stage: test
   script:
-  - bundle exec jekyll build -d test
+    - bundle exec jekyll build -d test
   artifacts:
     paths:
-    - test
+      - test
   rules:
     - if: '$CI_COMMIT_BRANCH != "master"'
 ```
@@ -345,7 +345,7 @@ workflow:
 
 cache:
   paths:
-  - vendor/
+    - vendor/
 
 before_script:
   - gem install bundler
@@ -354,20 +354,20 @@ before_script:
 pages:
   stage: deploy
   script:
-  - bundle exec jekyll build -d public
+    - bundle exec jekyll build -d public
   artifacts:
     paths:
-    - public
+      - public
   rules:
     - if: '$CI_COMMIT_BRANCH == "master"'
 
 test:
   stage: test
   script:
-  - bundle exec jekyll build -d test
+    - bundle exec jekyll build -d test
   artifacts:
     paths:
-    - test
+      - test
   rules:
     - if: '$CI_COMMIT_BRANCH != "master"'
 ```

doc/user/project/pages/introduction.md

@@ -118,14 +118,14 @@ is so `cp` doesn't also copy `public/` to itself in an infinite loop:
 ```yaml
 pages:
   script:
-  - mkdir .public
-  - cp -r * .public
-  - mv .public public
+    - mkdir .public
+    - cp -r * .public
+    - mv .public public
   artifacts:
     paths:
-    - public
+      - public
   only:
-  - master
+    - master
 ```
 
 ### `.gitlab-ci.yml` for a static site generator
@@ -161,13 +161,13 @@ image: ruby:2.6
 
 pages:
   script:
-  - gem install jekyll
-  - jekyll build -d public/
+    - gem install jekyll
+    - jekyll build -d public/
   artifacts:
     paths:
-    - public
+      - public
   only:
-  - pages
+    - pages
 ```
 
 See an example that has different files in the [`master` branch](https://gitlab.com/pages/jekyll-branched/tree/master)

doc/user/project/requirements/index.md

@@ -162,9 +162,9 @@ requirements, add a rule which checks `CI_HAS_OPEN_REQUIREMENTS` CI variable.
 ```yaml
 requirements_confirmation:
   rules:
-  - if: "$CI_HAS_OPEN_REQUIREMENTS" == "true"
-    when: manual
-  - when: never
+    - if: "$CI_HAS_OPEN_REQUIREMENTS" == "true"
+      when: manual
+    - when: never
   allow_failure: false
   script:
     - mkdir tmp