Should commands fail-fast like default GitHub action behavior?

[futureviperowner]

Describe the bug Depending on your perspective, this may not be a bug. However, if it's not then I think some documentation to make the expected behavior clearer would help users.

Default GitHub behavior for steps with a run command is to fail-fast when supported. This behavior exists for bash/sh/powershell scripts.

I discovered the retry action while attempting to troubleshoot a step of my GitHub workflow that's susceptible to an external race condition with the Azure CLI where retrying a specific step a few times is a simple way to deal with that race condition. After reading over the documentation, it seemed like close to a drop-in replacement for my existing run step. However, the action would never retry when the script encountered the expected failure because the last line of my command was a simple command that always succeeded.

az account set --subscription <some-sub-id>
az command_that_sometimes_fails
az account set --subscription <original-sub-id>

It's not hard to workaround this by adding set -e at the start of my command. But I was not expecting to have to do this and went through several rounds of adding debug calls and enabling debug logging until I realized it wasn't retrying because it was executing the final line even when the previous line failed.

Expected behavior IMO, it'd be great if the retry action supported the default GitHub run behavior (even if it's optional / opt-in) where the command fails-fast. However, if you disagree, then it's probably worth documenting this behavior so that people don't assume it behaves the same as a run step.

Screenshots n/a

Logs n/a

[genisd]

You could simply chain the commands with &&. Though i don't fully disagree, if there is command splitting logic (i saw something like that in the code, just glancing at it though), that is probably the nices behaviour.

Then again, just chaining with && or || depending on your needs should be fine