CI: a release still needs Every Python started by hand on the merged commit #1137

New issue

Closed

opened 2026-10-31 03:04:17 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-31 03:04:17 +00:00

Owner

What exists today

.forgejo/workflows/every-python.yml:17-26 triggers on pushes to "[0-9]*.[0-9]*.[0-9]*", a weekly cron and workflow_dispatch. CONTRIBUTING.md:696-700 (release step 5) asks the releaser to start Every Python on main by hand after the release pull request merges and wait for it, because scripts/release_tools.py:198-205 refuses a tag without a passed unit leg on every supported Python, and the push run tests 3.14 alone.

The candidate's cost half no longer holds. #1033 item 1 has landed (every-python.yml:19-22), so issue branches stopped triggering the two legs. The only release branch on the remote is origin/0.3.0, last committed 2026-09-16; since #940 every release goes through main, so the push trigger fires roughly never and costs nothing.

"Run the oldest Python only" is refuted: the release gate requires a passed leg on each of 3.12 and 3.13 (release_tools.py:199-205), and testing 3.12 alone would drop 3.13 from what a release promises.

What would change

Add a push trigger on main filtered by paths: (Forgejo honours paths; readme.yml:27-37 already uses it):

on:
  push:
    branches: [main]
    paths: ["src/postulo/__init__.py"]
  schedule:
    - cron: "47 6 * * 1"
  workflow_dispatch:

A push: key holds one branches/paths pair, so paths would also narrow pushes to release branches; since no release branch has been pushed since 2026-09-16 and every release now merges to main, the simplest form drops the release-branch filter. If the user wants release branches kept, they stay in branches: and accept the same paths narrowing. Release step 3 sets the version in src/postulo/__init__.py (and pyproject.toml, which release_tools.py check holds equal), so the release pull request's merge commit starts the legs by itself, and CONTRIBUTING.md step 5 and the hint at release_tools.py:204 change from "start it by hand" to "wait for it". The concurrency block already keys main on the commit. tests/test_release_tools.py reads this workflow and must still pass.

Adding uv.lock to the paths catches a dependency that drops an older Python's wheels on the day it lands rather than on Monday, at a cost: uv.lock changed in 16 commits between 2026-09-30 and 2026-10-30, about 7.5 runner-hours a month. pyproject.toml is no better a trigger: it changed in 17 commits in the same month, mostly dependency edits. src/postulo/__init__.py changed in six commits since 2026-09-01, the last on 2026-10-04.

What it saves or protects

small (workflow): one manual step and one wait fewer at each release; no runner time saved, a little spent

Accessibility

none

Decided by the maintainer (2026-10-31)

Every Python starts by itself on a push to main that changes src/postulo/init.py OR uv.lock (the user chose both, against the recommendation); release-branch trigger goes

Decisions

Start Every Python automatically on a version change on main? Recommended: yes, on src/postulo/__init__.py alone.
Also on uv.lock changes? Recommended: no; the weekly run and the release gate catch it before a release.
Drop the release-branch trigger? Recommended: yes, with this change; paths would narrow it anyway, and no release branch has been pushed since 0.3.0.

Found by the efficiency and reliability audit of 2026-10-30 (finding C10; index postulo/postulo#1108). Checked against main at daee30b15 (2026-10-30).

## What exists today `.forgejo/workflows/every-python.yml:17-26` triggers on pushes to `"[0-9]*.[0-9]*.[0-9]*"`, a weekly cron and `workflow_dispatch`. `CONTRIBUTING.md:696-700` (release step 5) asks the releaser to start *Every Python* on `main` by hand after the release pull request merges and wait for it, because `scripts/release_tools.py:198-205` refuses a tag without a passed unit leg on every supported Python, and the push run tests 3.14 alone. The candidate's cost half no longer holds. #1033 item 1 has landed (`every-python.yml:19-22`), so issue branches stopped triggering the two legs. The only release branch on the remote is `origin/0.3.0`, last committed 2026-09-16; since #940 every release goes through `main`, so the push trigger fires roughly never and costs nothing. "Run the oldest Python only" is refuted: the release gate requires a passed leg on each of 3.12 and 3.13 (`release_tools.py:199-205`), and testing 3.12 alone would drop 3.13 from what a release promises. ## What would change Add a push trigger on `main` filtered by `paths:` (Forgejo honours `paths`; `readme.yml:27-37` already uses it): ```yaml on: push: branches: [main] paths: ["src/postulo/__init__.py"] schedule: - cron: "47 6 * * 1" workflow_dispatch: ``` A `push:` key holds one `branches`/`paths` pair, so `paths` would also narrow pushes to release branches; since no release branch has been pushed since 2026-09-16 and every release now merges to `main`, the simplest form drops the release-branch filter. If the user wants release branches kept, they stay in `branches:` and accept the same `paths` narrowing. Release step 3 sets the version in `src/postulo/__init__.py` (and `pyproject.toml`, which `release_tools.py check` holds equal), so the release pull request's merge commit starts the legs by itself, and `CONTRIBUTING.md` step 5 and the hint at `release_tools.py:204` change from "start it by hand" to "wait for it". The `concurrency` block already keys `main` on the commit. `tests/test_release_tools.py` reads this workflow and must still pass. Adding `uv.lock` to the paths catches a dependency that drops an older Python's wheels on the day it lands rather than on Monday, at a cost: `uv.lock` changed in 16 commits between 2026-09-30 and 2026-10-30, about 7.5 runner-hours a month. `pyproject.toml` is no better a trigger: it changed in 17 commits in the same month, mostly dependency edits. `src/postulo/__init__.py` changed in six commits since 2026-09-01, the last on 2026-10-04. ## What it saves or protects small (workflow): one manual step and one wait fewer at each release; no runner time saved, a little spent ## Accessibility none ## Decided by the maintainer (2026-10-31) Every Python starts by itself on a push to main that changes src/postulo/__init__.py OR uv.lock (the user chose both, against the recommendation); release-branch trigger goes ## Decisions - **Start Every Python automatically on a version change on `main`?** Recommended: yes, on `src/postulo/__init__.py` alone. - **Also on `uv.lock` changes?** Recommended: no; the weekly run and the release gate catch it before a release. - **Drop the release-branch trigger?** Recommended: yes, with this change; `paths` would narrow it anyway, and no release branch has been pushed since 0.3.0. --- Found by the efficiency and reliability audit of 2026-10-30 (finding C10; index postulo/postulo#1108). Checked against `main` at `daee30b15` (2026-10-30).

tiagoagueda added this to the 0.6.0 milestone

2026-10-31 03:04:17 +00:00

tiagoagueda added the

performance

enhancement

labels

2026-10-31 03:04:17 +00:00

tiagoagueda referenced this issue

2026-10-31 03:04:41 +00:00

Efficiency and reliability audit of 2026-10-30: index #1108

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

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