fix: A release publishes without running the checks that gate a PR #84

New issue

Closed

opened 2026-09-09 23:06:40 +00:00 by ahmad · 0 comments

ahmad commented

2026-09-09 23:06:40 +00:00

Owner

Context

A release publishes and deploys without running any of the checks that gate a pull request.

Demonstrated on ahmad/larda on 2026-09-10: main failed pnpm typecheck, and v0.19.0 and v0.20.0 built, published and deployed anyway — version, publish, deploy and notify all green. The release workflow's jobs are version → publish → deploy → notify; none of them runs format, lint, type-check or tests. The image build compiles what it needs and nothing more.

How main came to be red matters, because it is the case this gap exists for: three pull requests landed within minutes, two of them adding a required field to a type, and the third had passed its checks before those fields existed. The merge was textually clean, so nothing refused it. A pull request can therefore be correct in isolation and wrong on arrival, and today nothing looks again after the merge.

The consequence is not a broken deployment — the break was in test files — but that is luck, not design. The same shape of staleness can reach production code, and the first signal would be the next pull request's pipeline failing for reasons that have nothing to do with it.

Scope

In: running the repository's own checks on main as part of, or as a gate on, the release flow in the shared template; failing the release rather than publishing when they do not pass.
Out: whether repositories should require an up-to-date branch before merge (ahmad/larda#76) — a different lever on the same problem, and worth having both.

Acceptance criteria

Given a main whose checks fail, when the release workflow runs, then no image is published and no deploy happens.
Given a main whose checks pass, when the release workflow runs, then the release proceeds as it does today.
Given a release blocked this way, then the notification says the checks failed rather than reporting a generic failure.
Given a repository whose checks are slow, then the added time is stated on this issue, so the cost is a decision rather than a surprise.
Given the template changes, then every consumer repository has a follow-up issue listed here.

### Context A release publishes and deploys without running any of the checks that gate a pull request. Demonstrated on `ahmad/larda` on 2026-09-10: `main` failed `pnpm typecheck`, and **v0.19.0 and v0.20.0 built, published and deployed anyway** — version, publish, deploy and notify all green. The release workflow's jobs are `version → publish → deploy → notify`; none of them runs format, lint, type-check or tests. The image build compiles what it needs and nothing more. How `main` came to be red matters, because it is the case this gap exists for: three pull requests landed within minutes, two of them adding a required field to a type, and the third had passed its checks before those fields existed. The merge was textually clean, so nothing refused it. A pull request can therefore be correct in isolation and wrong on arrival, and today nothing looks again after the merge. The consequence is not a broken deployment — the break was in test files — but that is luck, not design. The same shape of staleness can reach production code, and the first signal would be the next pull request's pipeline failing for reasons that have nothing to do with it. ### Scope - In: running the repository's own checks on `main` as part of, or as a gate on, the release flow in the shared template; failing the release rather than publishing when they do not pass. - Out: whether repositories should require an up-to-date branch before merge (`ahmad/larda#76`) — a different lever on the same problem, and worth having both. ### Acceptance criteria - [ ] Given a `main` whose checks fail, when the release workflow runs, then no image is published and no deploy happens. - [ ] Given a `main` whose checks pass, when the release workflow runs, then the release proceeds as it does today. - [ ] Given a release blocked this way, then the notification says the checks failed rather than reporting a generic failure. - [ ] Given a repository whose checks are slow, then the added time is stated on this issue, so the cost is a decision rather than a surprise. - [ ] Given the template changes, then every consumer repository has a follow-up issue listed here.

ahmad added the

labels

2026-09-09 23:06:49 +00:00

ahmad self-assigned this

2026-09-10 05:44:32 +00:00

ahmad added

state/in-progress

and removed