Step Status Conditional Workflow

JFrog Pipelines Documentation

JFrog Pipelines
Content Type
User Guide

With the status conditional workflow, you can configure a step to execute only if an input step’s status, during its current run, is satisfied. You can configure any number of statuses for a step.

YAML Schema

      - name: <step_name>
        type: <step_type>
                  allowFailure: boolean         #optional
            - name: <step_name>
                - <terminal_status>
                - <terminal_status>
                - <terminal_status>


It is important to note that the status of an input step in the current run only is considered for conditional workflows. If a step is not part of the current run, it is always assumed that the condition for that input step is met.

Adding Conditional Workflow for Steps

To add a conditional workflow for a step:

  1. In the inputSteps section of a step, add the status property.

  2. Add any of these values:

    • success

    • failure

    • error

    • cancelled

    • skipped

    • unstable

    • timeout


    Ensure that the values are in lowercase and use the same spelling as shown above. Any deviation from this will cause the pipeline source sync to fail.

    Example: In this example:

    • step_B has only one status: success

    • step_C has multiple statuses: failure, skipped, cancelled

          - name: step_A
            type: Bash
                      allowFailure: boolean         #optional
                - name: step_B
                    - success
                - name: step_C
                    - failure
                    - skipped
                    - cancelled
  3. allowFailure

    Optional: If you do not want a particular step to contribute to the final status of the run, you can add allowFailure: true to the configuration section of that step. When this option is used, even when a step fails or is skipped, the final status of the run is not affected.

    For example, a pipeline contains two steps S1 and S2:

    • Scenario 1: Step S2 is a cleanup step and its status is irrelevant. The overall run status should be determined by S1’s status and S2’s status should be ignored. In this case, add allowFailure: true to S2, since this is purely a cleanup step and only S1’s status should be taken into consideration.

    • Scenario 2: Step S1 has been configured to fail as part of the workflow. However S2 runs even if S1 fails and the run is not to be considered a failure. The run’s final status should mirror S2’s status since S1’s status does not interrupt the flow. In this case, add allowFailure: true to S1 since S1’s failure is a known possibility and expected, and that should not affect the final status of the run.

For more examples, see allowFailure Examples.