You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, when successfully blocking an issue, the action reports a failed state. This seems intentional, and I can understand why you've done it. However, this is the same response we'd expect to see when something went wrong and the action couldn't run to completion (eg. incomplete permissions, couldn't find an issue, etc.)
Desired behaviour
Allow the user to specify an input to determine whether blocking an issue should be considered a successful action, or a failure. (Default behaviour can remain the same.)
This means the action can still be used in longer workflows - and will continue to prevent them from completing if the issue is blocked, but users can optionally allow them to run quietly in the background without disruptively showing as errors, by setting fail-on-block: "false"
Workarounds
NB. Setting continue-on-error: true on the step is an OK workaround provided you trust that the action is working. It permits the action to complete without failing the workflow, but cannot distinguish between unintended errors and successfully blocking an issue.
The text was updated successfully, but these errors were encountered:
Context
At the moment, when successfully blocking an issue, the action reports a failed state. This seems intentional, and I can understand why you've done it. However, this is the same response we'd expect to see when something went wrong and the action couldn't run to completion (eg. incomplete permissions, couldn't find an issue, etc.)
Desired behaviour
Allow the user to specify an input to determine whether blocking an issue should be considered a successful action, or a failure. (Default behaviour can remain the same.)
eg. something like
This means the action can still be used in longer workflows - and will continue to prevent them from completing if the issue is blocked, but users can optionally allow them to run quietly in the background without disruptively showing as errors, by setting
fail-on-block: "false"
Workarounds
NB. Setting
continue-on-error: true
on thestep
is an OK workaround provided you trust that the action is working. It permits the action to complete without failing the workflow, but cannot distinguish between unintended errors and successfully blocking an issue.The text was updated successfully, but these errors were encountered: