Introduction

You can use Condition Tasks to put logic into your build, which helps avoid a rapid increase of plans or wrapping everything with script tasks.

If the condition evaluates to true, the tasks following it in the job are executed. If the condition evaluates to false, they are skipped.

By default, all tasks from the Condition Task to the end of the job are in scope for being skipped. However, you can configure the Condition Task to only execute or skip the next task or any number of subsequent tasks.

A user with global administration permissions can write Condition Tasks using a groovy script. Due to security considerations, non-admins cannot. Non-admins can, however, configure the number of tasks to be skipped and change the order of the configurable tasks.

To access these tasks, create a build plan, and add a stage and job. From there, click Add Task, and then ScriptRunner Condition Tasks.

Order of Execution

All these Condition Tasks are executed when the job is queued. Even if there are previous tasks in the job, the Condition Tasks are evaluated first to determine which of the tasks in the job should execute. This is true even if your Condition Task occurs late in the job.

Types

Build Variable Filtering Task

A Build Variable Filtering Task lets you conditionally execute subsequent tasks depending on build variables.

As there can be multiple repositories for a plan, there is not necessarily one branch. There could be many branches. planRepository.1.branch means "the branch for the first repository".

To create a build variable expression task, follow these steps:

  1. Enter the build variable expression in Expression.

    You can use a simple expression to check if a build variable has a particular value or more complex expressions where you can use boolean logic.

    The expression is evaluated as a Groovy script however for security reasons you are restricted to simple operations on build variables only. This means that only build variable names that are valid groovy variable names can be used. For build variables that don’t fit this pattern, you can access them as vars[variable.name]. For example, vars["planRepository.1.branch"].

    If the script returns true, or a truthy value, the subsequent tasks are executed. If not, they are skipped.

    Further examples can be found by clicking Show Snippets underneath the expression text.

  2. Enter how many tasks execute if the condition is true in Execute Task.

    build variable expression task

Path Filtering Task

A Path Filtering Task only executes subsequent tasks if the commit(s) that triggered the build contained files matching certain paths. These paths are provided in the form of ant globs, a simple way for matching paths.

For example, you may have a slow multi-module maven build. If all the files changed are in a single module, perhaps you wish to only build and run the tests for that module. Similarly, if only .mdfiles have changed, perhaps you want to only rebuild your documentation.

To create a path filtering task, follow these steps:

  1. Enter the path for the ant globs in Paths.

  2. Enter file matches in Match Type.

    If the script returns true, or a truthy value, the subsequent tasks are executed. If not, they are skipped.

  3. Enter how many tasks execute if the condition is true in Execute Tasks.

  4. Check the Ignore Non-Code Changes if the task is a code change.

    path matching task

Custom Script Condition

Custom script conditions can only be created by users with the global administrator permission, and the same permission is required to update the script that they run.

To add a custom script condition, follow these steps:

  1. Add your Inline Script.

    If the script returns true, or a truthy value, the subsequent tasks are executed. If not, they are skipped.

    You can write the script directly in the Script tab, or you can use the File tab to upload a script.
  2. Enter how many tasks you want to run if the condition is true in How Many Tasks.

  3. Save the task.

    custom task filter

As mentioned earlier, the code for all Condition Tasks runs on the server before any task in the job is executed. This is because you have access to the full Bamboo API, rather than just a subset as on a remote agent. Also, most things that you would want to check can be done when a job is first scheduled rather than during execution.

Have questions? Visit the Atlassian Community to connect, share, and learn with other Atlassian users and experts, including Adaptavist staff.

Ask a question about ScriptRunner for JIRA, Bitbucket Server, or Confluence.

Want to learn more? Check out courses on Adaptavist Learn, an online platform to onboard and train new users for Atlassian solutions.