Introduce a gate/check GHA job #10315
Conversation
| @@ -188,3 +188,17 @@ jobs: | |||
| fail_ci_if_error: true | |||
| files: ./coverage.xml | |||
| verbose: true | |||
|
|
|||
| check: # This job does nothing and is only used for the branch protection | |||
There was a problem hiding this comment.
^ this would have to go into the branch protection settings
| @@ -188,3 +188,17 @@ jobs: | |||
| fail_ci_if_error: true | |||
| files: ./coverage.xml | |||
| verbose: true | |||
|
|
|||
| check: # This job does nothing and is only used for the branch protection | |||
There was a problem hiding this comment.
Let's give it a better name than check
There was a problem hiding this comment.
Well, PyCA uses all-green, some use all-successful. I originally was going to recommend gate but a colleague convinced me that check is less confusing (because it doesn't fully map to https://gating.dev and openstack's understanding of gating).
This is why I left check in the action readme example so most people would just copy-paste that. For consistency, I'd have the same job id across the board but maybe specify a differing name: value?
There was a problem hiding this comment.
Different name is fine, it's just thst check is absolutely useless in terms of deriving meaning given gh naming schemes
Required-checks-agregate would be far more telling for example
Also there is possibly a need to limit who can change the dependencies
There was a problem hiding this comment.
Okay, I'll let the maintainers bikeshed on the name, then.
As for updating branch protection in the repo settings, it's usually available for the repo admins, I think.
There was a problem hiding this comment.
Ill give it a spin this evening
|
@RonnyPfannschmidt you could also bike shed post-merge. |
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. I was curious about the spread of use. And I've just discovered that it is now in use in aiohttp (and other aio-libs projects), CherryPy, some of the Ansible repositories, all of the jaraco's projects (like `setuptools`, `importlib_metadata`), some PyCQA, PyCA and pytest projects, a few AWS Labs projects. Admittedly, I maintain a few of these but it seems to address some of the pain folks have: jaraco/skeleton#55 (comment). The story behind this is explained in more detail at https://github.com/marketplace/actions/alls-green#why.
webknjaz
force-pushed
the
maintenance/gha-check
branch
from
0ad0930
to
30ce631
Compare
|
@RonnyPfannschmidt looks like this fell off your radar? |
Backport to 8.2.x: 💚 backport PR created✅ Backport PR branch: Backported as #12484 🤖 @patchback |
Introduce a gate/check GHA job (cherry picked from commit dc65bb6)
…c65bb6a6699bdeb5ee7523245db1ee724670e29/pr-10315 [PR #10315/dc65bb6a backport][8.2.x] Introduce a gate/check GHA job
webknjaz
added
the
type: infrastructure
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 burdenby a lot and have been battle-tested across a small bunch of projects
in its action form and in-house implementations of other people.
I was curious about the spread of use. And I've just discovered that
it is now in use in aiohttp (and other aio-libs projects), CherryPy,
some of the Ansible repositories, all of the jaraco's projects (like
setuptools,importlib_metadata), some PyCQA, PyCA and pytestprojects, a few AWS Labs projects. Admittedly, I maintain a few of
these but it seems to address some of the pain folks have:
jaraco/skeleton#55 (comment).
The story behind this is explained in more detail at
https://github.com/marketplace/actions/alls-green#why.