Update yaml codeblocks

Ran yamllint on yaml codeblocks to identify
minor formatting inconsistencies

doc/ci/caching/index.md

@@ -179,12 +179,12 @@ You can override cache settings without overwriting the global cache by using
 
 ```yaml
 cache: &global_cache
-    key: ${CI_COMMIT_REF_SLUG}
-    paths:
-      - node_modules/
-      - public/
-      - vendor/
-    policy: pull-push
+  key: ${CI_COMMIT_REF_SLUG}
+  paths:
+    - node_modules/
+    - public/
+    - vendor/
+  policy: pull-push
 
 job:
   cache:
@@ -281,7 +281,7 @@ image: python:latest
 # Change pip's cache directory to be inside the project directory since we can
 # only cache local items.
 variables:
-    PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
+  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
 
 # Pip's cache doesn't store the python packages
 # https://pip.pypa.io/en/stable/reference/pip_install/#caching

doc/ci/cloud_deployment/index.md

@@ -56,7 +56,7 @@ Some credentials are required to be able to run `aws` commands:
    ```yaml
    deploy:
      stage: deploy
-     image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest # see the note below
+     image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest  # see the note below
      script:
        - aws s3 ...
        - aws create-deployment ...

doc/ci/docker/using_kaniko.md

@@ -85,13 +85,13 @@ This can be solved by adding your CA's certificate to the kaniko certificate
 store:
 
 ```yaml
-  before_script:
-    - mkdir -p /kaniko/.docker
-    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
-    - |
-      echo "-----BEGIN CERTIFICATE-----
-      ...
-      -----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt
+before_script:
+  - mkdir -p /kaniko/.docker
+  - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
+  - |
+    echo "-----BEGIN CERTIFICATE-----
+    ...
+    -----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt
 ```
 
 ## Video walkthrough of a working example

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -228,6 +228,7 @@ deploy_terraform:
   stage: deploy
   script:
     # Your Review App deployment scripts - for a working example please check https://gitlab.com/Flockademic/Flockademic/blob/5a45f1c2412e93810fab50e2dab8949e2d0633c7/.gitlab-ci.yml#L315
+    - echo
 e2e:firefox:
   stage: confidence-check
   services:

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -566,15 +566,11 @@ Also set the variables `DB_HOST` to `mysql` and `DB_USERNAME` to `root`, which a
 We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-job).
 
 ```yaml
-...
-
 variables:
   MYSQL_DATABASE: homestead
   MYSQL_ROOT_PASSWORD: secret
   DB_HOST: mysql
   DB_USERNAME: root
-
-...
 ```
 
 #### Unit Test as the first job
@@ -584,8 +580,6 @@ We defined the required shell scripts as an array of the [script](../../yaml/REA
 These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`.
 
 ```yaml
-...
-
 unit_test:
   script:
     # Install app dependencies
@@ -598,8 +592,6 @@ unit_test:
     - php artisan migrate
     # Run tests
     - vendor/bin/phpunit
-
-...
 ```
 
 #### Deploy to production
@@ -615,8 +607,6 @@ The `only` keyword tells GitLab CI/CD that the job should be executed only when
 Lastly, `when: manual` is used to turn the job from running automatically to a manual action.
 
 ```yaml
-...
-
 deploy_production:
   script:
     # Add the private SSH key to the build environment

doc/ci/examples/php.md

@@ -73,24 +73,16 @@ Now that we created the script that contains all prerequisites for our build
 environment, let's add it in `.gitlab-ci.yml`:
 
 ```yaml
-...
-
 before_script:
   - bash ci/docker_install.sh > /dev/null
-
-...
 ```
 
 Last step, run the actual tests using `phpunit`:
 
 ```yaml
-...
-
 test:app:
   script:
     - phpunit --configuration phpunit_myapp.xml
-
-...
 ```
 
 Finally, commit your files and push them to GitLab to see your build succeeding
@@ -103,7 +95,7 @@ The final `.gitlab-ci.yml` should look similar to this:
 image: php:5.6
 
 before_script:
-# Install dependencies
+  # Install dependencies
   - bash ci/docker_install.sh > /dev/null
 
 test:app:
@@ -118,7 +110,7 @@ with a different Docker image version and the runner will do the rest:
 
 ```yaml
 before_script:
-# Install dependencies
+  # Install dependencies
   - bash ci/docker_install.sh > /dev/null
 
 # We test PHP5.6
@@ -231,8 +223,6 @@ In order to execute Composer before running your tests, simply add the
 following in your `.gitlab-ci.yml`:
 
 ```yaml
-...
-
 # Composer stores all downloaded packages in the vendor/ directory.
 # Do not use the following if the vendor/ directory is committed to
 # your git repository.
@@ -241,15 +231,13 @@ cache:
     - vendor/
 
 before_script:
-# Install composer dependencies
+  # 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
-
-...
 ```
 
 ## Access private packages or dependencies

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

@@ -19,27 +19,27 @@ This is what the `.gitlab-ci.yml` file looks like for this project:
 test:
   stage: test
   script:
-  - apt-get update -qy
-  - apt-get install -y nodejs
-  - bundle install --path /cache
-  - bundle exec rake db:create RAILS_ENV=test
-  - bundle exec rake test
+    - apt-get update -qy
+    - apt-get install -y nodejs
+    - bundle install --path /cache
+    - bundle exec rake db:create RAILS_ENV=test
+    - bundle exec rake test
 
 staging:
   stage: deploy
   script:
-  - gem install dpl
-  - dpl --provider=heroku --app=gitlab-ci-ruby-test-staging --api-key=$HEROKU_STAGING_API_KEY
+    - gem install dpl
+    - dpl --provider=heroku --app=gitlab-ci-ruby-test-staging --api-key=$HEROKU_STAGING_API_KEY
   only:
-  - master
+    - master
 
 production:
   stage: deploy
   script:
-  - gem install dpl
-  - dpl --provider=heroku --app=gitlab-ci-ruby-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY
+    - gem install dpl
+    - dpl --provider=heroku --app=gitlab-ci-ruby-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY
   only:
-  - tags
+    - tags
 ```
 
 This project has three jobs:

doc/ci/migration/circleci.md

@@ -120,7 +120,7 @@ stages:
   - build
   - test
   - deploy
-  
+
 job 1:
   stage: build
   script: make build dependencies
@@ -128,7 +128,7 @@ job 1:
 job 2:
   stage: build
   script: make build artifacts
-  
+
 job3:
   stage: test
   script: make test

doc/ci/migration/jenkins.md

@@ -238,7 +238,6 @@ case it will apply to all jobs in the pipeline:
 ```yaml
 my_job:
   image: alpine
-  ...
 ```
 
 #### `post`
@@ -284,7 +283,6 @@ stages:
 
 my_job:
   stage: build
-  ...
 ```
 
 #### `steps`
@@ -297,7 +295,6 @@ my_job:
   script:
     - echo "hello! the current time is:"
     - time
-  ...
 ```
 
 ### Directives

doc/ci/pipelines/pipeline_architectures.md

@@ -199,7 +199,7 @@ trigger_a:
     include: a/.gitlab-ci.yml
   rules:
     - changes:
-      - a/*
+        - a/*
 
 trigger_b:
   stage: triggers
@@ -207,7 +207,7 @@ trigger_b:
     include: b/.gitlab-ci.yml
   rules:
     - changes:
-      - b/*
+        - b/*
 ```
 
 Example child `a` pipeline configuration, located in `/a/.gitlab-ci.yml`, making

doc/ci/review_apps/index.md

@@ -130,20 +130,20 @@ deployed from its [project on GitLab.com](https://gitlab.com/gitlab-com/www-gitl
 
 ```yaml
 # Team data
-- source: 'data/team.yml' # data/team.yml
-  public: 'team/' # team/
+- source: 'data/team.yml'  # data/team.yml
+  public: 'team/'  # team/
 
 # Blogposts
-- source: /source\/posts\/([0-9]{4})-([0-9]{2})-([0-9]{2})-(.+?)\..*/ # source/posts/2017-01-30-around-the-world-in-6-releases.html.md.erb
-  public: '\1/\2/\3/\4/' # 2017/01/30/around-the-world-in-6-releases/
+- source: /source\/posts\/([0-9]{4})-([0-9]{2})-([0-9]{2})-(.+?)\..*/  # source/posts/2017-01-30-around-the-world-in-6-releases.html.md.erb
+  public: '\1/\2/\3/\4/'  # 2017/01/30/around-the-world-in-6-releases/
 
 # HTML files
-- source: /source\/(.+?\.html).*/ # source/index.html.haml
-  public: '\1' # index.html
+- source: /source\/(.+?\.html).*/  # source/index.html.haml
+  public: '\1'  # index.html
 
 # Other files
-- source: /source\/(.*)/ # source/images/blogimages/around-the-world-in-6-releases-cover.png
-  public: '\1' # images/blogimages/around-the-world-in-6-releases-cover.png
+- source: /source\/(.*)/  # source/images/blogimages/around-the-world-in-6-releases-cover.png
+  public: '\1'  # images/blogimages/around-the-world-in-6-releases-cover.png
 ```
 
 Mappings are defined as entries in the root YAML array, and are identified by a `-` prefix. Within an entry, there is a hash map with two keys:

doc/ci/ssh_keys/README.md

@@ -91,8 +91,8 @@ to access it. This is where an SSH key pair comes in handy.
      ## Optionally, if you will be using any Git commands, set the user name and
      ## and email.
      ##
-     #- git config --global user.email "user@example.com"
-     #- git config --global user.name "User name"
+     # - git config --global user.email "user@example.com"
+     # - git config --global user.name "User name"
    ```
 
    NOTE: **Note:**
@@ -193,8 +193,8 @@ before_script:
   ## Replace example.com with your private server's domain name. Repeat that
   ## command if you have more than one server to connect to.
   ##
-  #- ssh-keyscan example.com >> ~/.ssh/known_hosts
-  #- chmod 644 ~/.ssh/known_hosts
+  # - ssh-keyscan example.com >> ~/.ssh/known_hosts
+  # - chmod 644 ~/.ssh/known_hosts
 
   ##
   ## You can optionally disable host key checking. Be aware that by adding that
@@ -202,7 +202,7 @@ before_script:
   ## WARNING: Use this only with the Docker executor, if you use it with shell
   ## you will overwrite your user's SSH config.
   ##
-  #- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" >> ~/.ssh/config'
+  # - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" >> ~/.ssh/config'
 ```
 
 ## Example project

doc/ci/variables/README.md

@@ -131,10 +131,10 @@ After you set a variable, call it from the `.gitlab-ci.yml` file:
 test_variable:
   stage: test
   script:
-    - echo $CI_JOB_STAGE # calls a predefined variable
-    - echo $TEST # calls a custom variable of type `env_var`
-    - echo $GREETING # calls a custom variable of type `file` that contains the path to the temp file
-    - cat $GREETING # the temp file itself contains the variable value
+    - echo $CI_JOB_STAGE  # calls a predefined variable
+    - echo $TEST          # calls a custom variable of type `env_var`
+    - echo $GREETING      # calls a custom variable of type `file` that contains the path to the temp file
+    - cat $GREETING       # the temp file itself contains the variable value
 ```
 
 The output is:
@@ -511,7 +511,7 @@ build:
 deploy:
   stage: deploy
   script:
-    - echo $BUILD_VERSION # => hello
+    - echo $BUILD_VERSION  # => hello
   dependencies:
     - build
 ```
@@ -530,7 +530,7 @@ build:
 deploy:
   stage: deploy
   script:
-    - echo $BUILD_VERSION # => hello
+    - echo $BUILD_VERSION  # => hello
   needs:
     - job: build
       artifacts: true

doc/ci/yaml/README.md

@@ -490,7 +490,7 @@ include:
     file: '/templates/.gitlab-ci-template.yml'
 
   - project: 'my-group/my-project'
-    ref: 787123b47f14b552955ca2786bc9542ae66fee5b # Git SHA
+    ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
     file: '/templates/.gitlab-ci-template.yml'
 ```
 
@@ -1352,7 +1352,7 @@ job:
     - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/'
       when: manual
       allow_failure: true
-    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME' # Checking for the presence of a variable is possible
+    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'  # Checking for the presence of a variable is possible
 ```
 
 Some details regarding the logic that determines the `when` for the job:
@@ -1537,11 +1537,11 @@ docker build:
   script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
   rules:
     - if: '$VAR == "string value"'
-      changes: # Will include the job and set to when:manual if any of the follow paths match a modified file.
+      changes:  # Will include the job and set to when:manual if any of the follow paths match a modified file.
         - Dockerfile
         - docker/scripts/*
       when: manual
-  # - when: never would be redundant here, this is implied any time rules are listed.
+    # - when: never would be redundant here, this is implied any time rules are listed.
 ```
 
 Keywords such as `branches` or `refs` that are currently available for
@@ -3080,7 +3080,7 @@ For example, to match a single file:
 
 ```yaml
 test:
-  script: [ "echo 'test' > file.txt" ]
+  script: ["echo 'test' > file.txt"]
   artifacts:
     expose_as: 'artifact 1'
     paths: ['file.txt']
@@ -3093,7 +3093,7 @@ An example that will match an entire directory:
 
 ```yaml
 test:
-  script: [ "mkdir test && echo 'test' > test/file.txt" ]
+  script: ["mkdir test && echo 'test' > test/file.txt"]
   artifacts:
     expose_as: 'artifact 1'
     paths: ['test/']
@@ -3888,15 +3888,15 @@ ios-release:
   script:
     - echo 'iOS release job'
   release:
-     tag_name: v1.0.0-ios
-     description: 'iOS release v1.0.0'
+    tag_name: v1.0.0-ios
+    description: 'iOS release v1.0.0'
 
 android-release:
   script:
     - echo 'Android release job'
   release:
-     tag_name: v1.0.0-android
-     description: 'Android release v1.0.0'
+    tag_name: v1.0.0-android
+    description: 'Android release v1.0.0'
 ```
 
 #### `release:tag_name`
@@ -3968,25 +3968,24 @@ tags. These options cannot be used together, so choose one:
     script:
       - echo 'running release_job'
     release:
-       name: 'Release $CI_COMMIT_TAG'
-       description: 'Created using the release-cli $EXTRA_DESCRIPTION' # $EXTRA_DESCRIPTION must be defined
-       tag_name: '$CI_COMMIT_TAG'                                      # elsewhere in the pipeline.
-       ref: '$CI_COMMIT_TAG'
-       milestones:
-         - 'm1'
-         - 'm2'
-         - 'm3'
-       released_at: '2020-07-15T08:00:00Z'  # Optional, will auto generate if not defined,
-                                            # or can use a variable.
+      name: 'Release $CI_COMMIT_TAG'
+      description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION must be defined
+      tag_name: '$CI_COMMIT_TAG'                                       # elsewhere in the pipeline.
+      ref: '$CI_COMMIT_TAG'
+      milestones:
+        - 'm1'
+        - 'm2'
+        - 'm3'
+      released_at: '2020-07-15T08:00:00Z'  # Optional, will auto generate if not defined, or can use a variable.
   ```
 
 - To create a release automatically when commits are pushed or merged to the default branch,
   using a new Git tag that is defined with variables:
 
-NOTE: **Note:**
-Environment variables set in `before_script` or `script` are not available for expanding
-in the same job. Read more about
-[potentially making variables available for expanding](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6400).
+  NOTE: **Note:**
+  Environment variables set in `before_script` or `script` are not available for expanding
+  in the same job. Read more about
+  [potentially making variables available for expanding](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6400).
 
   ```yaml
   prepare_job:
@@ -4006,25 +4005,24 @@ in the same job. Read more about
     stage: release
     image: registry.gitlab.com/gitlab-org/release-cli:latest
     needs:
-    - job: prepare_job
-      artifacts: true
+      - job: prepare_job
+        artifacts: true
     rules:
       - if: $CI_COMMIT_TAG
-        when: never                                 # Do not run this job when a tag is created manually
-      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # Run this job when commits are pushed or merged to the default branch
+        when: never                                  # Do not run this job when a tag is created manually
+      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Run this job when commits are pushed or merged to the default branch
     script:
       - echo 'running release_job for $TAG'
     release:
-       name: 'Release $TAG'
-       description: 'Created using the release-cli $EXTRA_DESCRIPTION' # $EXTRA_DESCRIPTION and the $TAG
-       tag_name: '$TAG'                                                # variables must be defined elsewhere
-       ref: '$CI_COMMIT_SHA'                                           # in the pipeline. For example, in the
-       milestones:                                                     # prepare_job
-         - 'm1'
-         - 'm2'
-         - 'm3'
-       released_at: '2020-07-15T08:00:00Z'          # Optional, will auto generate if not defined,
-                                                    # or can use a variable.
+      name: 'Release $TAG'
+      description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION and the $TAG
+      tag_name: '$TAG'                                                 # variables must be defined elsewhere
+      ref: '$CI_COMMIT_SHA'                                            # in the pipeline. For example, in the
+      milestones:                                                      # prepare_job
+        - 'm1'
+        - 'm2'
+        - 'm3'
+      released_at: '2020-07-15T08:00:00Z'  # Optional, will auto generate if not defined, or can use a variable.
   ```
 
 #### `releaser-cli` command line
@@ -4659,9 +4657,9 @@ If you want to temporarily 'disable' a job, rather than commenting out all the
 lines where the job is defined:
 
 ```yaml
-#hidden_job:
-#  script:
-#    - run test
+# hidden_job:
+#   script:
+#     - run test
 ```
 
 You can instead start its name with a dot (`.`) and it won't be processed by