Run CI on an issue branch through its pull request alone (#1033) #1072

Merged

tiagoagueda merged 1 commit from 1033-ci-triggers into main

2026-10-28 17:59:56 +00:00

tiagoagueda commented

2026-10-28 13:45:26 +00:00

Owner

The push filter in ci.yml and every-python.yml was "[0-9]", written for
release branches (0.3.0). Since every issue got a branch named after its
number (#940) the glob matched them all, so one push to an issue branch
started CI on push, CI again on pull_request for the same commit, and
both Every Python legs: 122 runner-minutes on a two-slot runner where 48
test exactly as much. The filter is now "[0-9].[0-9].[0-9]", which a
release branch matches and no issue branch does. main keeps its push
run, which the release gate and the dev image's wait-ci read as (push)
statuses; pull requests run as before.

Both workflows gain a concurrency block, in the form dev-image.yml
already uses, so a newer push to the same pull request or branch cancels
the run it supersedes. main is never cancelled: on main the group is
keyed on the commit, and every group carries the event, so the weekly
run cannot cancel a push run of the same commit either.

CONTRIBUTING.md says to open the pull request when the branch is pushed,
as a draft (WIP:) if unfinished, and why. Two tests pin the filters and
the guard on main.

Item 1 of the issue; the others are separate work.

Refs #1033

Notes for review

Item 1 only. The other items of #1033 follow in their own pull requests, so this one says Refs #1033.
Push filter: "[0-9]*" → "[0-9]*.[0-9]*.[0-9]*" in ci.yml and every-python.yml, exactly the issue's change. Pushes to release branches and main still run CI; an issue branch is checked through its pull request alone, which halves the runs per push.
Concurrency: a group per workflow, event and PR number (or ref), with cancel-in-progress: true. main is keyed by commit SHA, so none of its runs are ever cancelled.
To check on the first PR after merging: that Forgejo evaluates expressions in concurrency.group. A second push to a PR should cancel the older run, and two pushes to main should both complete.
CONTRIBUTING: a new paragraph says to open the pull request early, as a WIP: draft if the work is unfinished, because that is how it gets CI.

🤖 Generated with Claude Code

The push filter in ci.yml and every-python.yml was "[0-9]*", written for release branches (0.3.0). Since every issue got a branch named after its number (#940) the glob matched them all, so one push to an issue branch started CI on push, CI again on pull_request for the same commit, and both Every Python legs: 122 runner-minutes on a two-slot runner where 48 test exactly as much. The filter is now "[0-9]*.[0-9]*.[0-9]*", which a release branch matches and no issue branch does. main keeps its push run, which the release gate and the dev image's wait-ci read as (push) statuses; pull requests run as before. Both workflows gain a concurrency block, in the form dev-image.yml already uses, so a newer push to the same pull request or branch cancels the run it supersedes. main is never cancelled: on main the group is keyed on the commit, and every group carries the event, so the weekly run cannot cancel a push run of the same commit either. CONTRIBUTING.md says to open the pull request when the branch is pushed, as a draft (WIP:) if unfinished, and why. Two tests pin the filters and the guard on main. Item 1 of the issue; the others are separate work. Refs #1033 ## Notes for review - **Item 1 only.** The other items of #1033 follow in their own pull requests, so this one says `Refs #1033`. - **Push filter:** `"[0-9]*"` → `"[0-9]*.[0-9]*.[0-9]*"` in `ci.yml` and `every-python.yml`, exactly the issue's change. Pushes to release branches and `main` still run CI; an issue branch is checked through its pull request alone, which halves the runs per push. - **Concurrency:** a group per workflow, event and PR number (or ref), with `cancel-in-progress: true`. `main` is keyed by commit SHA, so none of its runs are ever cancelled. - **To check on the first PR after merging:** that Forgejo evaluates expressions in `concurrency.group`. A second push to a PR should cancel the older run, and two pushes to `main` should both complete. - **CONTRIBUTING:** a new paragraph says to open the pull request early, as a `WIP:` draft if the work is unfinished, because that is how it gets CI. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

tiagoagueda added 1 commit

2026-10-28 13:45:26 +00:00

Run CI on an issue branch through its pull request alone (#1033 )

CI / Unit tests and coverage (Python 3.14) (pull_request) Successful in 15m18s

Details

CI / Checks: lint, migrations, catalogues, settings, built files (pull_request) Successful in 3m15s

Details

CI / Database tests on PostgreSQL (pull_request) Successful in 4m23s

Details

CI / Security audit (pull_request) Successful in 1m7s

Details

CI / Browser tests (Chromium) (pull_request) Successful in 34m37s

Details

1b12b55209

The push filter in ci.yml and every-python.yml was "[0-9]*", written for
release branches (0.3.0). Since every issue got a branch named after its
number (#940) the glob matched them all, so one push to an issue branch
started CI on push, CI again on pull_request for the same commit, and
both Every Python legs: 122 runner-minutes on a two-slot runner where 48
test exactly as much. The filter is now "[0-9]*.[0-9]*.[0-9]*", which a
release branch matches and no issue branch does. main keeps its push
run, which the release gate and the dev image's wait-ci read as (push)
statuses; pull requests run as before.

Both workflows gain a concurrency block, in the form dev-image.yml
already uses, so a newer push to the same pull request or branch cancels
the run it supersedes. main is never cancelled: on main the group is
keyed on the commit, and every group carries the event, so the weekly
run cannot cancel a push run of the same commit either.

CONTRIBUTING.md says to open the pull request when the branch is pushed,
as a draft (WIP:) if unfinished, and why. Two tests pin the filters and
the guard on main.

Item 1 of the issue; the others are separate work.

Refs #1033

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

tiagoagueda force-pushed 1033-ci-triggers from 1b12b55209

CI / Unit tests and coverage (Python 3.14) (pull_request) Successful in 15m18s

Details

CI / Checks: lint, migrations, catalogues, settings, built files (pull_request) Successful in 3m15s

Details

CI / Database tests on PostgreSQL (pull_request) Successful in 4m23s

Details

CI / Security audit (pull_request) Successful in 1m7s

Details

CI / Browser tests (Chromium) (pull_request) Successful in 34m37s

Details

to fec2ac6cbd