Thanks for the PR!

Some points to consider:

1. This changes the security levels: a small group of6 org owners + 8 repo admins can change the required checks via repo settings. With this PR, any of the ~90 active core devs can merge changes to this file. Is that okay? I think it's probably fine, we're not deploying or anything from here, but let's make sure.

2. Whilst this does reduce maintenance burden in administering which checks are required or not, is that something that needs changing often?
   For projects that test a big matrix of Python versions, it's definitely a plus: no need to add/remove version-specific checks via the interface once or twice a year. Maybe less so here?

3. Has this ~14 vs. ~90 been a bottleneck in the past?

@hugovk these are good points and I haven't considered some of them.

1. I should probably document the security considerations in README. It seems like this might be solvable by requiring reviews from code owners, for example. This should limit the scope of the CI updates made flying under the radar. It also occurred to me that the repository settings updates happen unnoticed, with no traceability for the larger public — only the admins would be able to see this in the security audit log and only if they specifically search for such changes. Whereas with the branch-protection-as-a-code, it's all there, verifiable viahttps://github.com/python/cpython/commits/main/.github/workflows/build.yml.
2. I've been offering similar PRs to many projects with matrixes of various sizes, and I've seen the maintainers forgetting to add new matrix factors. After all, it's a mental overhead having to memorize to perform some extra action items far from the place where you're editing the source code, especially since they aren't even in the code.
3. That's not something I can observe/verify 🤷‍♂️ — maybe@ezio-melotti knows?

I don't know if this is worth it for CPython as a number of jobs we require are outside of GitHub Actions (CLA, Issue Number, and News). So this check will increase complexity but won't actually solve the problem of bringing all required checks in one place.

@hugovk , as you've worked a lot of CI stuff lately across the various Python-org repos, do you have further feedback on this?

1. I should probably document the security considerations in README. It seems like this might be solvable by requiring reviews from code owners, for example.

Just to note, that would be a prettyhuge change in terms of workflow for this repo, sinceCODEOWNERS is used here for much more than just who isrequired to review certain changes. I'm not sure that itself is a dealbreaker for this proposal, but certainly something to keep in mind.

Agreed with@ambv: this looks like significant added complexity for not much actual gain in this project. It looks like a nice idea for some other setups, but doesn't feel like a great fit for us here. It's also possible I'm just missing the point, though :)

1. I should probably document the security considerations in README. It seems like this might be solvable by requiring reviews from code owners, for example.

Just to note, that would be a prettyhuge change in terms of workflow for this repo, sinceCODEOWNERS is used here for much more than just who isrequired to review certain changes.

FYI the SC has explicitly stated individuals cannot act as owners on any one piece of code (i.e. weall own the code), so requiringCODEOWNERS approval is a non-starter IMO.

Alright, so I'm closing this based on the latest feedback. Thanks for putting this together,@webknjaz, and sorry it wasn't a good match for us at this time!

Given that our requirements changed, with Auto-merge enabled, and more checks existing now, I would like to reconsider this PR for inclusion.

@webknjaz, would you be so kind as to adapt this to the current state ofmain?

@ambv so I just realized that the docs are its own workflow. The only way this is gonna work is wiring that in as a reusable workflow.

A quick summary of our in-person interaction. Łukasz and I agreed to implement the following:

• rename thecheck job ID and name
• convert the docs workflow into a reusable one
• integrate that into the mainbuild workflow, making use of the dynamic change detection that's already present there
• move the "allowed failures" declarations to the check

@ambv do we need to do the same to thebuild_msi workflow?

@ambv@hugovk I think this is ready.

@ambv@hugovk let's see if this is ready now...

@hugovk IIRC Łukasz and I talked about merging this PR but not changing the branch protection settings for a while so the check name would start being reported in the Checks widget on old PR updates, otherwise they'll get blocked until updated.

Thanks again!

GH-107114 is a backport of this pull request to the3.12 branch.

GH-107115 is a backport of this pull request to the3.11 branch.

UPD: this has been backported to 3.12 and 3.11 and the branch protection changed accordingly.