Table of Contents

GitLab CI

.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."

hide a job (.job)

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'

includes of another files

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"

extends: syntax

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

extends: syntax

<<: *my_anchor reuse properties with anchors

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 [.terraform, feature_destroy]

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]