.gitlab-ci.yml
stages: - deployless-test - build - deploy-to-dev - deploy-to-staging - staging-test - deploy-to-prod - deploy-to-prodint deployless-test: stage: deployless-test trigger: include: .gitlab-ci-test-deployless.yml strategy: depend build: stage: build trigger: include: .gitlab-ci-build.yml strategy: depend # deploy to dev from dev branch or any other except master (parallel deployments) deploy-to-dev: stage: deploy-to-dev rules: - if: $CI_COMMIT_BRANCH == "dev" when: on_success - if: $CI_COMMIT_BRANCH != "master" when: on_success variables: ENVIRONMENT: dev trigger: include: .gitlab-ci-deployto.yml strategy: depend ## if MASTER deploy-to-staging: stage: deploy-to-staging rules: - if: $CI_COMMIT_BRANCH == "master" variables: ENVIRONMENT: staging trigger: include: .gitlab-ci-deployto.yml strategy: depend staging-test: stage: staging-test rules: - if: $CI_COMMIT_BRANCH == "master" trigger: include: .gitlab-ci-test-ofdeployment.yml strategy: depend deploy-to-prod: stage: deploy-to-prod rules: - if: $CI_COMMIT_BRANCH == "master" variables: ENVIRONMENT: prod trigger: include: .gitlab-ci-deployto.yml strategy: depend deploy-to-prodint: stage: deploy-to-prodint rules: - if: $CI_COMMIT_BRANCH == "master" variables: ENVIRONMENT: prodint trigger: include: .gitlab-ci-deployto.yml strategy: depend
.gitlab-ci-test-deployless.yml
# no reason to run on launch-hub runner. Only required, when assuming IAM roles into the account. static_code_analysis: script: - echo "This job tests the code statically" unit_test: script: - echo "This job tests something, but takes more time than test-job1." - echo "After the echo commands complete, it runs the sleep command for 3 seconds" - echo "which simulates a test that runs 3 seconds longer than test-job1" - sleep 3 </code> .gitlab-ci-build.yml <code> # no reason to run on launch-hub runner. Only required, when assuming IAM roles into the account. build-job: image: name: openjdk:11-jdk-oracle script: - echo "Hello, $GITLAB_USER_LOGIN! Build here!" - java --version </code> .gitlab-ci-deployto.yml <code> # unfortunately "tags" keyword is not supported on jobs with "trigger" # https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html#define-multi-project-pipelines-in-your-gitlab-ciyml-file # hence runner-tags are defined here # UNCOMMENT - to run on a launch-hub runner # .runner-launchhub-tags: &runner-launchub # tags: # - LAUNCH-HUB # deployless_test deploy: # <<: *runner-launchub # runner tag script: - echo "This job deploys something from the '$CI_COMMIT_BRANCH' branch to environment '$ENVIRONMENT'." - echo "Pass the branch '$CI_COMMIT_BRANCH' to the deployment code here, to prefix all resources with '$CI_COMMIT_BRANCH'" </code> .gitlab-ci-test-ofdeployment.yml <code> # unfortunately "tags" keyword is not supported on jobs with "trigger" # https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html#define-multi-project-pipelines-in-your-gitlab-ciyml-file # hence runner-tags are defined here # UNCOMMENT - to run on a launch-hub runner # .runner-launchhub-tags: &runner-launchub # tags: # - LAUNCH-HUB staging-test-api: # <<: *runner-launchub # runner tag script: - echo "This job does API tests on STAGE." staging-test-ui: # <<: *runner-launchub # runner tag script: - echo "This job does UI tests on STAGE."
Start the job name with a dot (.) and it is not processed by GitLab CI/CD https://docs.gitlab.com/ee/ci/jobs/#hide-jobs
.terraform_image: &terraform_image name: hashicorp/terraform:light entrypoint: - '/usr/bin/env' - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
You can include - from a subfolder - from another gitlab-repository using “project” syntax
include: - gitlab_pipeline_jobs/shared.yml - gitlab_pipeline_jobs/deployment.yml - project: "mygroup/pipeline/autodevops" ref: master file: "templates/pipeline-cypress.yml"
You can use the “.extends” mechanism to refer to included modules, when the included modules shouldnt be activated automatically.
Instead you should include those with customized variables.
https://docs.gitlab.com/ee/ci/yaml/#extends
.tests: script: rake test stage: test only: refs: - branches rspec: extends: .tests script: rake rspec only: variables: - $RSPEC
Using anchors you can reuse attriburtes across jobs, especially from a disabled job:
.deployment: &deployment image: path/to/image.jpg tags: - LAUNCHTAG .deploy_to_prod: <<: *deployment variables: !reference [.env_variables, prod] .deploy_to_prodint: <<: *deployment variables: !reference [.env_variables, prodint]
Reference some piece of code. https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#reference-tags
Use the !reference custom YAML tag to select keyword configuration from other job sections and reuse it in the current section.
Unlike YAML anchors, you can use `!reference` tags to reuse configuration from included configuration files as well.
setup.yml
.setup: script: - echo creating environment
gitlab-ci.yml
include: - local: setup.yml .teardown: after_script: - echo deleting environment test: script: - !reference [.setup, script] - echo running my own command after_script: - !reference [.teardown, after_script]