Summary
A PR that targets anything other than main (or next) gets no CI at all — no unit tests, no build, no acceptance, no govulncheck. Stacked PRs are exactly that shape, and we use them.
Detail
.github/workflows/test.yml:
on:
pull_request:
branches:
- main.github/workflows/test-acceptance.yml:
on:
pull_request:
branches:
- next
- mainSo a PR based on a feature branch matches neither. Observed on #392, which targets feat/api-2026-09-01: the only checks that appeared were check-dependabot and [code]smith, both skipped. #378, which targets main, got the full set including three acceptance shards.
Why it matters
The stacked-PR workflow is the one where CI matters most: the whole point is to review a small change in isolation, and that is precisely the change nothing verifies. The failure is silent — the PR page shows no red, just an absence, which reads as "nothing to run" rather than "nothing ran".
Coverage does eventually arrive when the stack lands in a main-targeting PR and that re-runs, but by then the small reviewable unit has been merged into the large one, which is the opposite of the ordering you want.
Workaround
test.yml has workflow_dispatch: {}, so unit and build jobs can be triggered by hand:
gh workflow run test.yml --ref <branch>
This was done for #392 and passed (unit-test, govulncheck, build-mac/linux/windows). test-acceptance.yml has no workflow_dispatch, so acceptance cannot be triggered this way at all.
Suggested fix
Either add a wildcard so any PR runs the compile/unit/build tier:
on:
pull_request:
branches:
- '**'or, if the concern is acceptance tests hitting live APIs on every branch, split the tiers explicitly: unit/build/vuln on '**', acceptance on main/next as today. Adding workflow_dispatch to test-acceptance.yml would also make the manual path complete.
Related
Filed by Claude on Phil's behalf.
Summary
A PR that targets anything other than
main(ornext) gets no CI at all — no unit tests, no build, no acceptance, no govulncheck. Stacked PRs are exactly that shape, and we use them.Detail
.github/workflows/test.yml:.github/workflows/test-acceptance.yml:So a PR based on a feature branch matches neither. Observed on #392, which targets
feat/api-2026-09-01: the only checks that appeared werecheck-dependabotand[code]smith, both skipped. #378, which targetsmain, got the full set including three acceptance shards.Why it matters
The stacked-PR workflow is the one where CI matters most: the whole point is to review a small change in isolation, and that is precisely the change nothing verifies. The failure is silent — the PR page shows no red, just an absence, which reads as "nothing to run" rather than "nothing ran".
Coverage does eventually arrive when the stack lands in a
main-targeting PR and that re-runs, but by then the small reviewable unit has been merged into the large one, which is the opposite of the ordering you want.Workaround
test.ymlhasworkflow_dispatch: {}, so unit and build jobs can be triggered by hand:This was done for #392 and passed (unit-test, govulncheck, build-mac/linux/windows).
test-acceptance.ymlhas noworkflow_dispatch, so acceptance cannot be triggered this way at all.Suggested fix
Either add a wildcard so any PR runs the compile/unit/build tier:
or, if the concern is acceptance tests hitting live APIs on every branch, split the tiers explicitly: unit/build/vuln on
'**', acceptance onmain/nextas today. Addingworkflow_dispatchtotest-acceptance.ymlwould also make the manual path complete.Related
Filed by Claude on Phil's behalf.