Skip to content

docs(standard): keep _checks.yml per repo and record why the shared workflow was rejected #102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lesnik512 merged 1 commit into from
Sep 15, 2026
Merged

docs(standard): keep _checks.yml per repo and record why the shared workflow was rejected #102

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 12 additions & 9 deletions docs/standard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,9 +108,8 @@ minor and that minor's free-threaded build** (`3.14` and `3.14t` today). The mat
from the repo's floor to the newest, plus the free-threaded newest. The `Programming Language ::
Python :: 3.X` classifiers list every minor in the matrix.

In the shared checks workflow (section 7) the matrix is derived at run time from `requires-python`
and the newest released cycle, so no repo edits a matrix when a Python ships; a repo still on its
own `_checks.yml` maintains the list by hand.
The matrix is a hand-maintained list in each repo's `_checks.yml` (section 7), so a new Python is
a one-line change in every repo, made in one sweep.

## 7. CI

Expand All @@ -121,7 +120,7 @@ Two workflows per repo, both thin:
failure, opening or updating a tracking issue in the repo. This is how a dependency release or a
new Python that breaks the build becomes a ticket without anyone watching.

Both call one reusable `checks.yml` with these jobs:
Both call the repo's own reusable `_checks.yml`, which has these jobs:

| Job | What it does |
|---|---|
Expand All @@ -130,9 +129,12 @@ Both call one reusable `checks.yml` with these jobs:
| `links` | [lychee](https://github.com/lycheeverse/lychee-action) with `--offline`, remapping this repo's `blob/main` URLs to the checkout, so it fails only on a relative link or file path the diff broke |
| `docs` | `just docs-build` (`mkdocs build --strict`), only for repos with a docs site |

The shared `checks.yml` will live in `modern-python/.github` and be referenced at `main`, so a
change to it reaches every repo on merge; such a change is first exercised from a branch ref in
one repo. Until it exists, each repo carries the same jobs in a local `_checks.yml`.
`_checks.yml` is per repo by decision, not by omission. A shared workflow in `modern-python/.github`
was built and proven
([#95](https://github.com/modern-python/.github/issues/95)), and rejected on its interface: a
`workflow_call` input is a scalar, so a service container or an env map has to be flattened into
a string, and image knowledge ends up in the org repo. A change to the jobs is a sweep across the
repos instead, which is how the rest of this standard already lands.

## 8. Release

Expand All @@ -153,8 +155,9 @@ git tag -m "<repo> 3.4.0" 3.4.0 && git push origin 3.4.0
- The Release body is GitHub's generated notes from squashed PR titles, so a conventional-commit
PR title is the changelog entry. Prose goes in afterwards with `gh release edit`.

`release.yml` stays a per-repo file: PyPI does not accept a reusable workflow as a Trusted
Publisher. It is identical across repos apart from the comment naming the PyPI project.
`release.yml` could not be shared even if the checks were: PyPI does not accept a reusable
workflow as a Trusted Publisher. It is identical across repos apart from the comment naming the
PyPI project.

## 9. Repository files

Expand Down
Loading