Atlas Bench blog

Dynamic Step Condition for Bitbucket Pipelines

Written by Riley Venable | Dec 31, 2025, 8:48:16 PM

Dynamic step condition is a new Bitbucket Pipelines feature that runs or skips a step based on a boolean expression over pipeline variables, evaluated just before the step starts. Expressions can use output variables from earlier steps, so deployments can be gated on live signals such as security scan results, but secured and vault variables are not accessible.

Bitbucket Pipelines has become a cornerstone for teams aiming to deliver software efficiently and reliably. The latest enhancement introduces dynamic step conditions, empowering teams to skip or execute steps based on real-time pipeline variables. This advancement moves beyond static triggers, enabling pipelines to respond to live signals such as output from earlier steps or centrally managed variables. The result is a smarter, safer, and more flexible automation process that aligns with the realities of modern software delivery. Automation thrives when it adapts to what matters most at any given moment. Whether responding to security scan results, deployment freezes, or change impact checks, dynamic step conditions bring decision-making closer to the point of action. This reduces manual intervention, eliminates redundant work, and ensures that only necessary steps are executed. Over time, this approach leads to more predictable workflows, reduced build times, and a better developer experience. Atlas Bench, as an Atlassian Solution Partner, specializes in designing and optimizing Bitbucket Pipelines for organizations of all sizes. Our expertise lies in building resilient CI/CD patterns that balance speed and safety, especially in complex or regulated environments. With dynamic step conditions now available, we see new opportunities to enhance consistency and observability across teams by embedding these controls into shared templates and deployment projects.

What is Dynamic Step Condition

Dynamic step condition is a new feature that allows you to define a state condition within a pipeline step. This condition evaluates a boolean expression using variables from the pipeline context. If the expression is true, the step runs; if false, the step is skipped. Evaluation occurs just before the step starts, ensuring that the most current information is used. The feature supports a range of operators and functions, making it versatile for various use cases. Previously, pipelines could only use static conditions based on information known before execution, such as branch names or file changes. There was no way to leverage data generated during the pipeline run, like the results of a security scan. Teams often resorted to workarounds, such as splitting pipelines or embedding logic within scripts, which increased complexity and risk. Dynamic step conditions eliminate these challenges by allowing pipelines to make decisions based on real-time context. The benefits are clear: unnecessary steps are skipped, saving time and resources; safety is enhanced by gating critical actions on up-to-date information; and the overall pipeline becomes easier to read, review, and maintain. Teams can now combine static and dynamic conditions for even greater control, ensuring that deployments only occur when all relevant criteria are met.

Key Use Cases

Blocking deployments during incidents is a common requirement. By setting a workspace variable, such as block deployment, teams can instantly pause production deployments without editing pipeline code. This centralized control is invaluable during incidents or release freezes, allowing for quick and coordinated responses. The variable can be toggled in the Bitbucket UI, and the condition will take effect immediately for subsequent steps. Security is another critical area. Pipelines often include steps that scan for vulnerabilities. With dynamic step conditions, the results of these scans can be exported as pipeline variables, such as critical count. Downstream deployment steps can then check this variable and only proceed if no critical vulnerabilities are found. This approach ensures that production deployments are automatically gated by the latest security findings, reducing the risk of introducing vulnerabilities. Combining changesets and state conditions provides granular control. For example, a deployment step can be configured to run only if files in a specific directory have changed and no critical vulnerabilities are present. This prevents unnecessary deployments and ensures that only relevant changes trigger production updates.

How Dynamic Step Condition Works

Implementing dynamic step conditions starts with identifying the variables you need. These can include workspace, repository, deployment, or pipeline output variables. Define a condition block within the step and create a boolean expression that references these variables. For multi-step pipelines, ensure that output variables are properly exported so they are available to downstream steps. Evaluation timing is crucial. For automatic steps, the condition is checked just before the step starts, reflecting the latest variable values. For manual steps, evaluation occurs when the user initiates the step. This ensures that decisions are always based on the most current information. Testing is essential. Use echo statements in your scripts to print variable values and review the build setup log for details on how conditions are evaluated. If an expression is invalid or references a missing variable, the step will be skipped, maintaining safety.

Expression Syntax and Variables

Dynamic step conditions support a variety of variable types, including default variables provided by Bitbucket, workspace and repository variables set in the UI, deployment variables for environment-specific settings, and pipeline output variables generated by earlier steps. Expressions must resolve to a boolean value and can use comparison, logical, and grouping operators, as well as the glob function for pattern matching. Variables are treated as strings by default unless they are explicitly booleans or numbers. Bitbucket infers the expected type based on the comparison in the expression. Avoid unnecessary quotes when storing string values, as this can affect how expressions are evaluated. Secured and vault variables are not accessible to state expressions. If you need to gate a step based on a secure value, emit a non-sensitive signal as a pipeline output variable instead.

Evaluation Timing and Special Cases

For automatically triggered steps, conditions are evaluated immediately before execution. This ensures that any changes to variables, such as toggling a deployment freeze, are respected in real time. For manual steps, evaluation occurs when the user initiates the step, allowing for last-minute checks. Steps with retry strategies re-evaluate the condition on each retry, which is useful when external factors may change. Steps queued in concurrency groups evaluate the condition when queued and do not re-evaluate upon resumption. To avoid race conditions, limit parallel steps that write to the same variable keys.

Best Practices and Recommendations

Promote safety by validating expressions in lower environments before rolling out to production. Use changesets to narrow the scope of deployments and combine them with state conditions for runtime checks. Centralize high-impact toggles in workspace variables and restrict modification rights to authorized personnel. Keep conditions simple and readable. When logic becomes complex, move parsing into earlier steps that emit simple boolean or numeric results. Standardize variable names and storage conventions across projects to prevent subtle evaluation issues. Leverage detailed logs for troubleshooting. The build setup log provides valuable insights into how conditions are evaluated and which variables are used. Adopt diagnostic steps that can be enabled when needed, such as printing variable inventories or running dry-run evaluations.

Wrapping Up

Dynamic step conditions transform Bitbucket Pipelines from static rule sets into responsive workflows that act on live signals. Teams can now gate critical steps on real-time data, improving safety, efficiency, and clarity. By combining static and dynamic conditions, pipelines become more adaptable and easier to manage. If you are considering adopting dynamic step conditions in your pipelines, Atlas Bench can help you design, pilot, and scale these patterns across your organization. Our experts can integrate these controls with your security, incident, and change management processes, ensuring a smooth transition and lasting benefits.