With the recent addition of advanced logic in a config file, the option to conditionally trigger steps in a job or to conditionally trigger a workflow is now available.
Specific logic statements can be used to create multiple nested conditions, that will always at the top level result in true or false -- which in turn determines if the workflow or steps are triggered.
| Type | Arguments | true if | Example |
|---|---|---|---|
| YAML literal | None | is truthy | true/42/"a string" |
| YAML alias | None | resolves to a truthy value | *my-alias |
| Pipeline Value | None | resolves to a truthy value | << pipeline.git.branch >> |
| Pipeline Parameter | None | resolves to a truthy value | << pipeline.parameters.my-parameter >> |
| and | N logic statements | all arguments are truthy | and: [ true, true, false ] |
| or | N logic statements | any argument is truthy | or: [ false, true, false ] |
| not | 1 logic statements | the argument is not truthy | not: true |
| equal | N values | all arguments evaluate to equal values | equal: [ 42, << pipeline.number >>] |
| matches | pattern and value | value matches the pattern | matches: { pattern: "^feature-.+$", value: << pipeline.git.branch >> } |
The following logic values are considered falsy:
false null 0 NaN empty strings (“”) statements with no arguments
All other values are truthy. Also note that using logic with an empty list will cause a validation error.
Logic statements always evaluate to a boolean value at the top level, and coerce as necessary. They can be nested in an arbitrary fashion, according to their argument specifications, and to a maximum depth of 100 levels.
matches uses Java regular expressions for its pattern. A full match pattern must be provided, prefix matching is not an option. Though, it is recommended to enclose a pattern in ^ and $ to avoid accidental partial matches.
Note: When using logic statements at the workflow level, do not include the condition: key (the condition key is only needed for job level logic statements).