A dispatched Every Python run records no commit statuses, so the release gate never sees it #1189

New issue

Closed

opened 2026-11-01 07:47:38 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-11-01 07:47:38 +00:00

Owner

What happened

Releasing 0.5.0 (2026-11-01), CONTRIBUTING's Making a release step 5 was followed as written: #1188 merged as 8ce017c18, then Actions → Every Python started by hand on main. Run 1841 passed on 3.12 and 3.13, on 8ce017c18.

release_tools.py check v0.5.0 --ci, which the release workflow runs on the tag, still said:

no unit tests on Python 3.12 for 8ce017c18: a push tests the newest Python only; start *Every Python* by hand on this commit for the rest
no unit tests on Python 3.13 for 8ce017c18: ...

Forgejo records no commit statuses for a workflow_dispatch run: the commit's statuses list only CI / … (push) and Dev image / … (push). The gate reads commit statuses only (_statuses, REQUIRED_JOBS), so a dispatched Every Python can never satisfy it, however green it is.

Why it worked for 0.4.0

Until #1033, every-python.yml ran on pushes to "[0-9]*", which matched issue branches. So a merged commit usually already carried Every Python / Unit tests … (push) statuses from its branch. #1033 (rightly) narrowed the filter to release branches [0-9]*.[0-9]*.[0-9]*, and that closed the path the gate had been relying on without anyone noticing.

What got 0.5.0 out

Pushing the release branch at the merged commit, git push origin <sha>:refs/heads/0.5.0, as 0.3.0 had a 0.3.0 branch. Its push runs ci.yml and every-python.yml with statuses on the same commit. The cost is a second full CI run (about 45 min), since ci.yml also runs on release branches.

To do

CONTRIBUTING Making a release step 5: replace "start Actions → Every Python on main" with pushing the X.Y.Z release branch at the merged commit, and say why (a dispatched run records no statuses the gate can read).
The gate's message in release_tools.py (_problems) says "start Every Python by hand on this commit", which is exactly what does not work. Point it at the release branch instead.
every-python.yml's header and CONTRIBUTING:97 ("whenever it is started by hand") should say a dispatched run is for looking, not for the gate.
Optional: avoid the duplicate CI run. One way is to push the release branch before merging the release PR, from the PR's head, but a squash makes a new commit, so it would then have to be a fast-forward merge. Another is to have the gate also accept a successful every-python.yml run on the commit, read from the actions runs API, which does list dispatched runs with their commit_sha. The second keeps the documented step and is the smaller change.
A test in tests/test_release_tools.py for whichever is chosen.

🤖 Generated with Claude Code

## What happened Releasing 0.5.0 (2026-11-01), CONTRIBUTING's *Making a release* step 5 was followed as written: #1188 merged as `8ce017c18`, then *Actions → Every Python* started by hand on `main`. Run 1841 passed on 3.12 and 3.13, on `8ce017c18`. `release_tools.py check v0.5.0 --ci`, which the release workflow runs on the tag, still said: ``` no unit tests on Python 3.12 for 8ce017c18: a push tests the newest Python only; start *Every Python* by hand on this commit for the rest no unit tests on Python 3.13 for 8ce017c18: ... ``` Forgejo records **no commit statuses for a `workflow_dispatch` run**: the commit's statuses list only `CI / … (push)` and `Dev image / … (push)`. The gate reads commit statuses only (`_statuses`, `REQUIRED_JOBS`), so a dispatched *Every Python* can never satisfy it, however green it is. ## Why it worked for 0.4.0 Until #1033, `every-python.yml` ran on pushes to `"[0-9]*"`, which matched issue branches. So a merged commit usually already carried `Every Python / Unit tests … (push)` statuses from its branch. #1033 (rightly) narrowed the filter to release branches `[0-9]*.[0-9]*.[0-9]*`, and that closed the path the gate had been relying on without anyone noticing. ## What got 0.5.0 out Pushing the release branch at the merged commit, `git push origin <sha>:refs/heads/0.5.0`, as 0.3.0 had a `0.3.0` branch. Its push runs `ci.yml` and `every-python.yml` with statuses on the same commit. The cost is a second full CI run (about 45 min), since `ci.yml` also runs on release branches. ## To do - [ ] CONTRIBUTING *Making a release* step 5: replace "start *Actions → Every Python* on `main`" with pushing the `X.Y.Z` release branch at the merged commit, and say why (a dispatched run records no statuses the gate can read). - [ ] The gate's message in `release_tools.py` (`_problems`) says "start *Every Python* by hand on this commit", which is exactly what does not work. Point it at the release branch instead. - [ ] `every-python.yml`'s header and CONTRIBUTING:97 ("whenever it is started by hand") should say a dispatched run is for looking, not for the gate. - [ ] Optional: avoid the duplicate CI run. One way is to push the release branch *before* merging the release PR, from the PR's head, but a squash makes a new commit, so it would then have to be a fast-forward merge. Another is to have the gate also accept a successful `every-python.yml` run on the commit, read from the actions runs API, which does list dispatched runs with their `commit_sha`. The second keeps the documented step and is the smaller change. - [ ] A test in `tests/test_release_tools.py` for whichever is chosen. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

tiagoagueda added this to the 0.6.0 milestone

2026-11-01 07:47:47 +00:00

tiagoagueda added the

bug

documentation

labels

2026-11-01 07:47:47 +00:00

tiagoagueda referenced this issue from a pull request that will close it,

2026-11-10 10:31:54 +00:00

0.6.0 fixes, bunch 1: CI and workflows #1223

tiagoagueda referenced this issue from a commit

2026-11-10 10:31:55 +00:00