Conditional runs
The conditions listed in this article can be applied to the entire pipelines and/or individual actions – except for Run if action status is/is not which can be used only in actions.
Adding conditions
Actions
To add conditions to actions, go to the Conditions tab in the specific action:
Image loading...
Pipelines
To add a condition to the pipeline, go to the pipeline settings and switch to the Run if tab:
Image loading...
You can combine multiple trigger conditions with OR and AND:
Image loading...
Run on change in path
You can configure pipelines and actions to run only when files in specific repository paths change.
Certain actions can be skipped if they are not used to speed up pipeline execution. In other words, if you have an action that compiles your assets, you can skip it if there were no changes in the path that requires compilation. For example, upon setting
if (changeset contains "assets/")
the action or pipeline will be run only if there were changes to the assets path in the repository.
Image loading...
You can also expand the condition to any update in the repository by setting:
if (changeset is not "empty")
Run on payload
A pipeline run can carry a payload - a set of files uploaded together with the run request. Payload conditions let you decide what runs based on those files, e.g. skip the deployment when nobody sent a new configuration.
There are two payload conditions:
- Payload is not empty - runs if the current run received any payload files
- Payload contains path - runs if at least one payload file matches one of the given paths (glob patterns such as
config/**are supported)
In YAML, the conditions look like this:
yamltrigger_conditions: - trigger_condition: ON_PAYLOAD
yamltrigger_conditions: - trigger_condition: ON_PAYLOAD_AT_PATH trigger_condition_paths: - "config/**" - "release.json"
Sending a payload
The quickest way to attach a payload is the --payload option of the Buddy CLI:
bashbdy pipeline run start deploy -b main --payload ./release$
When you pass a directory, its contents are uploaded with their relative paths preserved, e.g. ./release/config/app.json lands as config/app.json in the pipeline filesystem. A single file lands in the root of the filesystem. You can also upload payload files through the REST API and pass them in the run request.
The run view lists the payload files, and actions whose payload condition was not met are marked as skipped:
Image loading...
The list of files delivered with the current run is available in the $BUDDY_RUN_PAYLOAD_FILES variable, so your commands can process exactly what was sent:
bashecho "$BUDDY_RUN_PAYLOAD_FILES"$
config/** just because the files from a previous run are still there.
Run depending on the triggering user
Although Buddy features customizable permissions for pipelines, you can also use conditions to further restrict run permissions to individual users or groups.
By defining conditions, you can specify that a pipeline should only run if it is triggered by a specific user. On the other hand, you can also prevent a pipeline from running for a certain user. This ensures that the pipeline will not be triggered by that user, even if they have the necessary permissions.
Additionally, you can restrict the ability to run the pipeline for users belonging (or not) to a specific group.
if (invoker is/is not "user_name")
if (invoker is in group/is not in group "group_name")
Image loading...
Run depending on the day and time
Conditional executions also offer the ability to schedule pipelines and/or actions to run at specific days and times.
if (day is "day" in "timezone_name")
if (hour is "hour" in "timezone_name")
Image loading...
Run if the pipeline passed with the same revision
With this option, you can configure a pipeline to run only if the selected pipeline run for this revision has been successful. The most common use-case for this condition is to ensure that your production pipeline doesn't run if the testing pipeline for the same revision failed to pass beforehand.
if ("pipeline_name" in "project_name" passed with the same revision)
Image loading...
Run depending on the action status
The following condition can be set in actions only. To add it, go to the Conditions tab in the action.
This condition allows you to determine whether an action should be triggered based on the status of another action. The feature lets your pipeline respond intelligently to the outcome of previous actions, e.g. by sending different notifications depending on the action that failed.
if ("action_name" status is success / failed / skipped / suppressed)
Image loading...
Run depending on ENV VAR value
Variables are extremely handy when you need to be precise about what you want to run and when. Here you can use Buddy's default variables, parameters defined in the Pass Params action, and your own custom variables.
Run depending on output of previous action
- Add a custom variable (e.g.
$OUTPUT) and set it as settable. - Add a container action and enter the condition that will define the value of the variable, for example:
bashexport OUTPUT=expected_value$
Image loading...
- Add another action and set the condition to check if the value of the variable is correct:
if ($OUTPUT is "expected_value")
Image loading...
Run depending on parameters passed on pipeline run
The Pass Arguments action allows you to create and pass parameters as environment variables during pipeline execution. This way you change the behavior of a pipeline that's already in progress.
For example, you can set a true/false parameter asking if you want to notify your clients of the new version on your Slack channel:
Image loading...
The second step is setting a condition in the Slack action to check if the answer was positive:
if ($sendNotification is "true")
Image loading...
Once triggered, the action will ask you to select the argument that will be passed to the Slack notification:
Image loading...
Run only for specific branch
If you have a wildcard pipeline and want to run an action on changes in a specific branch (e.g. integration tests on the master branch), you can use $BUDDY_RUN_BRANCH as the condition variable in the target action:
if ($BUDDY_RUN_BRANCH is "branch_name")
Image loading...
Run only if commit message contains specific phrase
The last example of variable-based conditions is listening for a keyword in the commit message.
if ($BUDDY_RUN_COMMIT_MESSAGE contains "phrase")
Image loading...
Skip draft pull requests
Draft pull requests trigger pipelines just like regular ones, with $BUDDY_RUN_PR_DRAFT set to true. To keep quick checks on drafts but save the heavy steps until the pull request is ready for review, add this condition to the expensive actions:
if ($BUDDY_RUN_PR_DRAFT is not "true")
yamltrigger_conditions: - trigger_condition: VAR_IS_NOT trigger_variable_key: BUDDY_RUN_PR_DRAFT trigger_variable_value: "true"
Actions with a condition are marked with an IF badge in the pipeline:
Image loading...
is not "true" rather than is "false". The variable is not set in runs that were not started by a pull request event, so an is "false" condition would skip the action in those runs as well.
On GitLab, marking a merge request as ready starts a new run right away, with the full set of actions. On other providers, the full set of actions runs on the next pull request event, e.g. the next push to the pull request branch.
Checking condition results
Every run shows how its conditions were evaluated. When an action is skipped, open its logs to see the condition, the result, and the actual value Buddy compared against:
Run if: $BUDDY_RUN_PR_DRAFT is not true - not met (actual: true)
Run if: Payload contains config/** (matched: config/**)
This makes it easy to tell a misconfigured condition from a run that simply had nothing to do.
Last modified on Oct 29, 2026