Commit 57c427fc authored by Nick Gaskill's avatar Nick Gaskill

Merge branch 'docs-fix-yaml' into 'master'

Clean up yaml code blocks in CI docs

See merge request gitlab-org/gitlab!41651
parents 28e23846 75361309
......@@ -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
......
......@@ -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 ...
......
......@@ -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
......
......@@ -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:
......
......@@ -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
......
......@@ -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
......
......@@ -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:
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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:
......
......@@ -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
......
......@@ -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
......
......@@ -491,7 +491,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'
```
......@@ -1353,7 +1353,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:
......@@ -1538,11 +1538,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
......@@ -3085,7 +3085,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']
......@@ -3098,7 +3098,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/']
......@@ -3893,15 +3893,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`
......@@ -3973,25 +3973,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:
......@@ -4011,25 +4010,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
......@@ -4664,9 +4662,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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment