Step Status Conditional Workflow

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

    steps:
      - name: <step_name>
        type: <step_type>
        configuration:
                  allowFailure: boolean         #optional
          inputSteps:
            - name: <step_name>
              status:
                - <terminal_status>
                - <terminal_status>
                - <terminal_status>

Note

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:

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

Add any of these values:

success
failure
error
cancelled
skipped
unstable
timeout

Note

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
        configuration:
                  allowFailure: boolean         #optional
          inputSteps:
            - name: step_B
              status:
                - success
            - name: step_C
              status:
                - failure
                - skipped
                - cancelled

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.