Keywords: GitLab CI | Conditional Statements | Continuous Integration
Abstract: This article provides an in-depth exploration of various methods to implement conditional logic in GitLab CI/CD pipelines. By analyzing four main approaches—shell variables, YAML multiline blocks, GitLab rules, and template inheritance—the paper compares their respective use cases and implementation details. With concrete code examples, it explains how to dynamically execute deployment tasks based on different environment variables and branch conditions, while offering practical advice for troubleshooting and performance optimization.
Introduction
In modern continuous integration and continuous deployment (CI/CD) workflows, the execution of conditional logic is crucial for ensuring the flexibility and reliability of automated processes. GitLab CI, as a widely adopted CI/CD tool, offers multiple mechanisms to implement conditional branching, enabling dynamic adjustment of pipeline behavior based on environment variables, code changes, or other contextual factors.
Shell Variable Method
Using shell variables is one of the most straightforward ways to implement conditional logic. By defining conditional statements in the script section, different execution paths can be selected based on predefined variable values.
deploy-dev:
image: testimage
environment: dev
tags:
- kubectl
script:
- if [ "$flag" == "true" ]; then MODULE="demo1"; else MODULE="demo2"; fi
- kubectl apply -f ${MODULE} --record=true
The advantage of this method lies in its simplicity and compatibility with standard shell scripting. The value of the environment variable $flag determines the final deployment module, and the intermediate variable MODULE avoids redundant command writing.
YAML Multiline Block Syntax
For more complex conditional logic, the YAML multiline block syntax can be used to write complete shell script fragments.
deploy-dev:
image: testimage
environment: dev
tags:
- kubectl
script:
- >
if [ "$flag" == "true" ]; then
kubectl apply -f demo1 --record=true
else
kubectl apply -f demo2 --record=true
fi
The multiline block syntax uses the > symbol to treat subsequent content as a complete string, maintaining code readability. This method is particularly suitable for conditional branches containing multiple commands, but attention must be paid to indentation and newline handling.
GitLab Rules System
GitLab provides a dedicated rules configuration item for defining execution conditions at the job level, which is the most aligned with GitLab CI's design philosophy.
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
when: never
- if: '$CI_PIPELINE_SOURCE == "push"'
when: never
- when: always
The rules system supports complex conditional judgments based on predefined variables (e.g., CI_PIPELINE_SOURCE), allowing precise control over job execution timing. The advantage of this method is its declarative syntax and deep integration with the GitLab ecosystem.
Template Inheritance and Variable Override
Through GitLab CI's template inheritance mechanism, reusable job templates can be created, and conditional execution can be achieved via variable overrides.
.deploy-dev:
image: testimage
environment: dev
tags:
- kubectl
script:
- kubectl apply -f ${MODULE} --record=true
demo1-deploy-dev:
extends: .deploy-dev
only:
variables: [ $flag == "true" ]
variables:
MODULE: demo1
demo2-deploy-dev:
extends: .deploy-dev
only:
variables: [ $flag == "false" ]
variables:
MODULE: demo2
This method inherits the base template via the extends keyword, uses only conditions to restrict job execution, and overrides variable values in the template via variables. This architecture supports high code reusability and clear separation of responsibilities.
Common Issues and Solutions
In practical use, developers may encounter various execution errors. The curl command execution issue mentioned in the reference article reveals important details about shell command parsing.
When executing external commands in conditional statements, attention must be paid to how command arguments are passed. Incorrect quoting can prevent commands from being correctly recognized:
# Incorrect example
if [ -f "test.txt" ]; then
'curl https://www.website1.com';
else
'curl https://www.website2.com';
fi
This approach causes the shell to treat the entire single-quoted string as a single command name, resulting in a "command not found" error. The correct approach is to avoid unnecessary quoting of the complete command:
# Correct example
if [ -f "test.txt" ]; then
curl https://www.website1.com
else
curl https://www.website2.com
fi
Performance Considerations and Best Practices
When choosing a conditional implementation method, execution efficiency and maintenance costs must be considered. The shell variable method executes fastest but has limited logical complexity; the rules system offers the best readability and maintainability but may require more configuration.
For simple conditional judgments, the shell variable or YAML multiline block syntax is recommended. For complex pipeline logic, especially scenarios involving multiple environments or branches, the rules system and template inheritance provide better scalability.
Conclusion
GitLab CI offers multiple flexible ways to implement conditional statements, each with specific applicable scenarios. Developers should choose the most suitable solution based on specific business needs, team technology stack, and maintenance requirements. By properly utilizing these conditional mechanisms, flexible and reliable CI/CD pipelines can be constructed, significantly improving the efficiency and quality of software delivery.