Fail the Run
Ends this device's branch as a failure, with a reason you write. It is how a workflow says no.
End this device's branch as a failure, with your own reason. Put it after the false branch of an Assert so a failed check is recorded as a failed run.
Reach for it when
- The false side of an Assert, when a failed check should mean a failed run.
- A log search that found the crash you were looking for.
Every setting this block has. A field marked only when appears once you have chosen the mode above it — those are alternatives to each other, not extra things to fill in.
- ReasonRequiredstarts at Check failed
Shown on the step, in the run log and in the run record — write what a person reading the report tomorrow needs, e.g. Cart total was {{ $Dump UI.json.elements[0].label }}, expected 3 items.
Put it where the run should stop being green
Before this block existed, the unhappy branch of a check just ran off the end and the run was still recorded as a success — a nightly regression could report green with every check in it failed.
Assert / Verify · falseFail the Run— nothing —Write a reason a person can act on
It is shown on the step, in the run log and in the run record. Reference an upstream value so the reason carries the evidence with it.
Fail the RunSettings ReasonRequiredCart showed {{ $Dump UI.json.count }} items, expected 3Nothing continues past it
The node has no output — that is the node. Other devices carry on; this one's branch is over.
Fail the RunIdle
- Nothing. The branch ends, and the run is recorded as failed.
- It ends this device's branch, not the whole run. Four phones passing and one failing is one failed run with one failed device, which is what you want.
- A run with no Fail the Run anywhere is a run that can only fail by accident — a step erroring out. Checks that merely take the false branch stay silent.