9. Job control

In this section we will show you different options how to control the job execution. Sometimes some jobs will be used only in certain branches, or for example you will execute a stage only if the commit is tagged with a Semver number .

9.1: Job control

You can use only and except or rules to control when to add jobs to pipelines.

Use only to define when a job runs. Use except to define when a job does not run.

Use the only:refs and except:refs keywords to control when to add jobs to a pipeline based on branch names or pipeline types.

9.2: Execution control

KeywordMethod
on_sucess(default) - Execute job only when all jobs in earlier stages succeed, or are considered successful because they have allow_failure: true.
on_failureExecute job only when at least one job in an earlier stage fails.
alwaysExecute job regardless of the status of jobs in earlier stages.
manualExecute job manually.
delayedDelay the execution of a job for a specified duration
neverDon’t execute job.

9.3: Failure control

Use allow_failure when you want to let a job fail without impacting the rest of the CI suite. The default value is false, except for manual jobs that use the when: manual syntax.

Task 9.4: Job control lab

  • Add a new Job named deploy_to_prod to a new deploy stage
  • Add a manual pipeline gate to make sure a manual action is required to execute this job
  • Add a new Job execution rule, the job should run only on the release branch
  • Add a script block with a simple echo command

Commit and push these changes to the main branch and go to Build –> Pipelines and check the pipeline status. You may notice that the job deploy_to_prod is not visible. This is because we add an execution rule for the release branch only. To fix this, we need to switch back to Repository –> Branches and create a new branch called release.

Now the pipeline should run again and we can see the newly created job. After the pipeline executed successfully, you may notice that the deploy step wasn’t executed yet and isn’t marked with a green tick. This is because we configured the job as a manual action. To trigger this job, we need to select the job and do it manually.

manual_job

Solution

Updated .gitlab-ci.yml file for this lab:

show solution
stages:
  - info
  - build
  - test
  - package
  - deploy

variables:
  GIT_STRATEGY: 'clone'
  COMPILE: 'false'
  IMAGE_HOST: 'quay.io'
  IMAGE_REPOSITORY: 'puzzle'
  IMAGE_NAME: 'example-spring-boot'

default:
  timeout: 5 minutes

info:
  stage: info
  retry: 2
  script:
    - echo "This is your first stage (ツ)"
    - echo "Username is ${USERNAME} with ${PASSWORD}"

build_application:
  stage: build
  tags:
    - build
    - mobiliar
  image: registry.access.redhat.com/ubi9/openjdk-17:latest
  script:
    - ./gradlew assemble

test_application:
  stage: test
  image: registry.access.redhat.com/ubi9/openjdk-17:latest
  script:
    - ./gradlew check
  artifacts:
    when: always
    reports:
      junit: build/test-results/test/**/TEST-*.xml

build_image:
  image: diemobiliar.azurecr.io/dlp-cicd-dockercli-image:254
  tags:
    - build
    - mobiliar
  services:
    - docker:dind
  stage: package
  before_script:
    - docker info
  script:
    - docker build --no-cache -t $IMAGE_NAME .
    - IMAGE_PATH=$IMAGE_HOST/$IMAGE_REPOSITORY/$IMAGE_NAME:${CI_COMMIT_SHA:0:8}
    - echo "docker image path is - $IMAGE_PATH"
    - docker tag $IMAGE_NAME $IMAGE_PATH
    # - docker login -u ${DOCKER_USERNAME} -p ${DOCKER_PASSWORD} ${IMAGE_HOST}
    # - docker push $IMAGE_PATH

deploy_to_prod:
  stage: deploy
  when: manual
  only:
   - release
  script:
    - echo "Deployment triggered"

9.5: Rules

Available since GitLab 12.3.

Rules are evaluated in the specified order - until the first one matches. Depending on the configuration, the job is then either in - or excluded from the pipeline.

rules accepts an array of rules defined with:

  • if
  • changes
  • exists
  • allow_failure
  • variables
  • when

Important: rules replaces only/except. Thus they can not be used together in the same job. If you configure a job using both keywords, GitLab will return a key may not be used with rules error!

Task 9.6: Job control using rules

  • Change the deploy_to_prod job to use rules instead.

Commit and push these changes to the release branch. It should behave exactly the same as in the previous exercise.

Solution

Updated .gitlab-ci.yml file for this lab:

show solution
stages:
  - info
  - build
  - test
  - package
  - deploy

variables:
  GIT_STRATEGY: 'clone'
  COMPILE: 'false'
  IMAGE_HOST: 'quay.io'
  IMAGE_REPOSITORY: 'puzzle'
  IMAGE_NAME: 'example-spring-boot'

default:
  timeout: 5 minutes

info:
  stage: info
  retry: 2
  script:
    - echo "This is your first stage (ツ)"
    - echo "Username is ${USERNAME} with ${PASSWORD}"

build_application:
  stage: build
  tags:
    - build
    - mobiliar
  image: registry.access.redhat.com/ubi9/openjdk-17:latest
  script:
    - ./gradlew assemble

test_application:
  stage: test
  image: registry.access.redhat.com/ubi9/openjdk-17:latest
  script:
    - ./gradlew check
  artifacts:
    when: always
    reports:
      junit: build/test-results/test/**/TEST-*.xml

build_image:
  image: diemobiliar.azurecr.io/dlp-cicd-dockercli-image:254
  tags:
    - build
    - mobiliar
  services:
    - docker:dind
  stage: package
  before_script:
    - docker info
  script:
    - docker build --no-cache -t $IMAGE_NAME .
    - IMAGE_PATH=$IMAGE_HOST/$IMAGE_REPOSITORY/$IMAGE_NAME:${CI_COMMIT_SHA:0:8}
    - echo "docker image path is - $IMAGE_PATH"
    - docker tag $IMAGE_NAME $IMAGE_PATH
    # - docker login -u ${DOCKER_USERNAME} -p ${DOCKER_PASSWORD} ${IMAGE_HOST}
    # - docker push $IMAGE_PATH

deploy_to_prod:
  stage: deploy
  rules:
    - if: '$CI_COMMIT_BRANCH == "release"'
      when: manual
  script:
    - echo "Deployment triggered"
Previous
Next
Last modified September 25, 2023: Add empty line for linter (bb023a9)