A wait step waits for all previous steps to have successfully completed before allowing following jobs to continue.
A wait step can be defined in your pipeline settings, or in your pipeline.yml file. It can be placed between steps to ensure that previous steps are successful before continuing to run the rest.
Run the next step, even if the previous step has failed.
A boolean expression that omits the step when false. See Using conditionals for supported expressions.
A list of step keys that this step depends on. This step will only proceed after the named steps have completed. See managing step dependencies for more information.
Whether to continue to proceed past this step if any of the steps named in the
You can also configure the wait step to continue even if the previous steps failed. If steps failed, the build will be marked as failed only after any steps after the
continue_on_failure: true have completed.
This is useful for processing results from previous steps, for example, test coverage or summarizing test failures. Successful steps that run after a
continue_on_failure step will not affect the status of the build; if there has been a failure, the build will be marked as failed.
In the example below, if
command.sh succeeds, both of the following command steps will be run. If
command.sh fails, only the first will be run, and the build will then be marked as failed.
steps: - command: "command.sh" - wait: ~ continue_on_failure: true - command: "echo This runs regardless of the success or failure" - wait - command: "echo The command passed"
If there's a failure followed by a regular wait step, nothing after the wait step will run, including any subsequent wait steps with
continue_on_failure: true. In the example below, when the first command fails, the second and third commands will not run:
Any wait steps with
continue_on_failure: true that aren't separated by regular wait steps will all run if a failure occurs. In the below example, after the first command fails, the second, third, and fourth commands will all run:
The explicit null
~ character used in the above examples isn't required, but is recommended as a best practice. It ensures that nothing else is accidentally added to the
wait before the
If a block step follows or precedes a wait step in your build, the wait step will be ignored and only the block step will run, like in this example:
But let's consider a different example. Now the wait step (with
continue_on_failure: true) will be ignored, but the block step will also not run, because the 'previous' command step failed.
If you need to run a block step after a failed step, set soft_fail on the failing step: