You can use condition expressions to control whether a job runs in a pipeline. This topic provides common scenarios with examples.
The condition field accepts an expression that can reference environment variables. In the following example, the condition for job2 references the system environment variable for the code source branch, "${CI_COMMIT_REF_NAME}" == "develop". job2 runs only when the pipeline executes on the develop branch. Otherwise, the job is skipped.
sources:
my_repo:
type: gitSample
name: sample code source
endpoint: https://atomgit.com/flow-example/spring-boot.git
branch: master
stages:
stage1:
name: stage1
jobs:
command_job1:
name: job1
steps:
command_step:
name: Run command 1
step: Command
with:
run: |
echo This is Job1
stage2:
name: stage 2
jobs:
command_job2:
name: job2
# Condition: Execute this job when the branch is develop.
condition: |
"${CI_COMMIT_REF_NAME}" == "develop"
steps:
command_step:
name: Run command 2
step: Command
with:
run: echo This is Job2
stage3:
name: stage 3
jobs:
command_job3:
name: job3
steps:
command_step:
name: Run command 3
step: Command
with:
run: echo This is Job3
command_job4:
name: job4
needs: command_job3
steps:
command_step:
name: Run command 4
step: Command
with:
run: echo This is Job4Example 1: Skip frontend build if not updated, build only the backend application
When frontend and backend applications have dependencies, the frontend is typically built first to produce static files consumed by the backend build. Because not every change involves the frontend, you can skip its build conditionally. In this example, a custom pipeline variable "${FRONT_APP_CHANGED}" == "true" is used as the job condition. If the value is true, the frontend build runs; otherwise, it is skipped.
After the pipeline run completes, the condition expression "false" == "true" appears below the Build a Frontend Application job, indicating that the condition was not met. The job is skipped and shows a duration of 0 seconds. The Build a Backend Application and Deploy Job jobs run as expected, and the pipeline completes successfully.
On the Variables and Cache tab of the pipeline, select Variables. In the Runtime Selection Variables section, add a variable named FRONT_APP_CHANGED with a default value of true, the options true,false, and the description "Environment variable to indicate if the frontend application was modified."
sources:
my_repo:
type: gitSample
name: sample code source
endpoint: https://atomgit.com/flow-example/spring-boot.git
branch: master
stages:
build_stage:
name: Build
jobs:
front_build_job:
name: Build a frontend application
# Decide whether to build the frontend application based on custom environment variables.
condition: |
"${FRONT_APP_CHANGED}" == "true"
steps:
command_step:
name: Run a command
step: Command
with:
run: |
echo This is front app build job...
backend_build_job:
name: Build a backend application
needs: front_build_job
steps:
command_step:
name: Run a command
step: Command
with:
run: |
echo This is backend app build job...
deploy_stage:
name: deploy
jobs:
deploy_job:
name: Deploy_job
steps:
command_step:
name: Run a command
step: Command
with:
run: echo This is deploy job...Example 2: Non-window period releases require manual review, while window period releases can skip manual review
In production release scenarios, manual review is required outside of the release window, but can be bypassed during the window.
sources:
my_repo:
type: gitSample
name: sample code source
endpoint: https://atomgit.com/flow-example/spring-boot.git
branch: master
stages:
build_stage:
name: Build
jobs:
build_job:
name: Build_job
steps:
command_step:
name: Run a command
step: Command
with:
run: |
echo This is build job...
approve_stage:
name: approval
jobs:
approve_job:
name: Manual review
# Execute the approval job when the working branch is master. Replace with the actual approval criteria.
condition: |
"${CI_COMMIT_REF_NAME}" == "master"
component: ManualValidate
with:
validatorType: users # The type of the validator is a member of the organization. Identify the reviewer by using the Alibaba Cloud ID.
validateMethod: and # Verification method and: countersign (all approvers must agree) or: or sign (one approver can agree or reject).
validators:
- 290591284908846966 # Obtain the Alibaba Cloud ID from the Alibaba Cloud Management Console.
deploy_stage:
name: deploy
jobs:
deploy_job:
name: Deploy_job
steps:
command_step:
name: Run a command
step: Command
with:
run: echo This is deploy job...Example 3: Deploy to multiple environments on demand at a time
When multiple testing environments are available, you can deploy to a specific environment on demand by specifying the environment name.
On the pipeline editor page, select the Variables and Cache tab. In the left pane, click Variables. In the Runtime Selection Variables area, add an environment name variable named ENVNAME, with a default value of ENV1, and the options ENV1,ENV2.
sources:
my_repo:
type: gitSample
name: sample code source
endpoint: https://atomgit.com/flow-example/spring-boot.git
branch: master
stages:
build_stage:
name: Build
jobs:
build_job:
name: Build_job
steps:
command_step:
name: Run a command
step: Command
with:
run: |
echo This is build job...
deploy_stage:
name: Deploy a test environment
jobs:
deploy_job1:
name: Deploy test environment 1
# Deploy on-demand based on the specified environment name.
condition: |
"${ENVNAME}" == "ENV1"
steps:
command_step:
name: Run a command
step: Command
with:
run: echo This is deploy env 1...
deploy_job2:
name: Deploy test environment 2
# Deploy on-demand based on the specified environment name.
condition: |
"${ENVNAME}" == "ENV2"
steps:
command_step:
name: Run a command
step: Command
with:
run: echo This is deploy env 2...