I also feel that the philosophy used by GitHub to handle this feature is flawed. As a user:
- I add sets of assertions to ensure that my code is correct. This means that, by default, these assertions must pass.
- For some reason (mainly performance-related), I may decide not to run certain assertions because they're not relevant to the changes in the PR. This use case is correctly handled by the GHA syntax, using the if feature.
- And lastly, in exceptional cases, a job may be flaky, and for agility reasons, I might want to be able to merge even if some jobs fail. But this set of jobs is limited, and I should take an explicit action to allow them to fail — and, in theory, this is temporary. So maintaining this list is actually desired.
As a consequence, the default should be that all jobs must pass (no need to maintain a long list of jobs, or to break run optionality), and the exception should be to list flaky jobs (which is fine, since it's a short list).
But currently, the philosophy is exactly the opposite: all jobs are allowed to fail by default (with no option to switch to the other behavior), unless we explicitly list them as required. As a result, we must either:
- Maintain a long list of required jobs, which breaks the optionality (actually a no-go),
- Or create a unique mandatory dedicated job — we call it all-green — that check all others jobs, and explicitly list the flaky jobs as exceptions.
It really seems to me that this has been designed the wrong way 😢. The consequences of such a bad default are significant, especially considering that GitHub is by far the most widely used centralized repository. I'm genuinely surprised that there has been no reaction from GitHub.
.png)

