Introduce a gate/check GHA job

[webknjaz]

This adds a GHA job that reliably determines if all the required dependencies have succeeded or not.

It also allows to reduce the list of required branch protection CI statuses to just one — check. This reduces the maintenance burden by a lot and have been battle-tested across a small bunch of projects in its action form and in-house implementations of other people.

It is now in use in aiohttp (and other aio-libs projects), CherryPy, attrs, coveragepy, conda some of the Ansible repositories, pip-tools, pydantic, spaceship-prompt, Towncrier, all of the jaraco's projects (like setuptools, importlib_metadata), some PyCQA, PyCA, PyPA and pytest projects, a few AWS Labs projects.

The story behind this is explained in more detail at https://github.com/marketplace/actions/alls-green#why.

[jorisroovers]

So we currently don't have any branch protection rules setup for gitlint. In fact, I still fairly regularly push directly to main (after running tests locally and sometimes using force push to fix issues on main). I realize I should stop doing that 😅 I never merge other branches into main directly though, that I always do via a PR.

Given that only @sigmavirus24 and I have commit permission on this repo this hasn't really been an issue.

My understanding is that this PR is only useful in case branch permissions have been setup. I've used branch protection rules before but I'm interested to hear your advise on some best-practices wrt branch protection rules. Thanks!

[webknjaz]

My understanding is that this PR is only useful in case branch permissions have been setup. I've used branch protection rules before but I'm interested to hear your advise on some best-practices wrt branch protection rules. Thanks!

There are other useful bits to this:

• in the graph view at https://github.com/jorisroovers/gitlint/actions/runs/3516847917, there is a distinct check that represents the overall outcome of the workflow, it's easier to spot, less mental overhead
• the PR checks lists, it'd be marked as required — it's a useful signal to the contributors who may not know whether all the jobs are expected to fail or of some are unstable and are fine to fail — this also reduces the mental load
• it is useful when you enable the auto-merge feature — having a branch protection check would enable you to click auto-merge on PRs and switch to other things knowing that it'll be merged when and if the CI passes, no need to baby-sit the CI, waiting for the change to click Merge only after that

Regarding the push privileges, you can have a branch protection rule for the sake of setting the expectations but still allow the administrators to push to the branch, bypassing the mandatory checks. This means that both direct pushes and force-merges will still work.

[jorisroovers]

Ok. Seems like it has mostly mental load benefits for gitlint at this point, but allows for more powerful automation when branch protection and auto-merge features would be used - something you've now got me thinking about :-)

Merging this in - thanks for submitting and educating me along the way!