Failing the job if a change is detected

[lukepighetti]

I've been discussing with a colleague if the best practice with committing changed code to a PR branch (such as formatted / generated code) is to have the action fail or succeed. I was wondering if you would comment on this.

Arguments for success

• The action technically did succeed
• It's easier to implement, as this is the default behavior

Arguments for fail

• The action succeeded only because the codebase was in a failing state (code out of date, needed to be updated)
• Failing will block an automerge, and you want a chance for the checks to run on the subsequent PR

[stefanzweifel]

As always in programming, I would say: It depends. :)

I personally haven't come across a scenario, where it would make sense to make a job fail, if the job can "fix" code and commit the changes automatically.

A failed job …

• might also send an email/slack notification to me and others.
• attracts my and others attention to something, that doesn't need attention. The job can fix the problem itself.

A failed job also signifies to me, that I should take a closer look, as something that should be automated failed. For example when running automated tests, a dependency update could break something. That problem can't easily be solved automatically.
Badly formatted code can be fixed. So why not let the "bots" do their thing, while we focus on solving problems?

---

Have you come across scenarios and workflows, where it would make sense to make the job fail?
I have to say, that I have thought about adding support for this in the past, but couldn't come up with a good example, when this could be useful.
As of right now, I think users could implement this also by themself by listening to the output variables from this Action.