Every release-plz PR arrives with zero status checks and is therefore blocked by branch protection. It is not specific to #187; it will happen on every release cycle from now on.
What happens
release-plz pushes its branch using GITHUB_TOKEN, and GitHub deliberately does not trigger workflow runs for pushes made with that token (it is the same rule the comment at the top of delivery.yml already relies on: "GITHUB_TOKEN-created tags do not trigger new workflow runs").
So on #187's head sha:
$ gh api repos/encryption4all/postguard/commits/f047b83/check-runs
total_count: 0
and main requires two contexts:
Wire compat (published pg-core)
Wire compat (published pg-wasm/pg-js)
mergeStateStatus is BLOCKED, with nothing red to point at, because nothing ran at all. Same failure shape as #273: the gate looks fine and is doing nothing.
Workaround used on #187
Closing and reopening the PR. build.yml and api-diff.yml both list reopened in their pull_request types:, so the full matrix runs and the required contexts report. It does not touch the branch or the release content.
That works, but it is a manual step someone has to know about on every release, and if they do not know it, the release PR simply sits there looking blocked. Which is how #273 went unnoticed for two weeks.
Options
- Give release-plz a PAT or GitHub App token instead of
GITHUB_TOKEN. Pushes from a non-GITHUB_TOKEN identity do trigger workflows, so the release PR gets CI like any other. This is the documented release-plz recommendation and removes the manual step. Costs a secret to manage.
- Document the close/reopen dance in
CLAUDE.md and accept it. Free, but relies on the human remembering.
- Leave the release PR out of required checks. Not recommended: its diff includes
Cargo.lock, which is exactly the input the wire-compat gate exists to watch.
Option 1 is the real fix. Option 2 is worth doing regardless, because until the token changes, anyone looking at a stuck release PR needs to know why.
Related: #273 (the last time a release-pipeline failure was invisible), #275 (the guard for that one). Part of the "fail closed, fail loud" line in #247.
Every release-plz PR arrives with zero status checks and is therefore blocked by branch protection. It is not specific to #187; it will happen on every release cycle from now on.
What happens
release-plz pushes its branch using
GITHUB_TOKEN, and GitHub deliberately does not trigger workflow runs for pushes made with that token (it is the same rule the comment at the top ofdelivery.ymlalready relies on: "GITHUB_TOKEN-created tags do not trigger new workflow runs").So on #187's head sha:
and
mainrequires two contexts:mergeStateStatusisBLOCKED, with nothing red to point at, because nothing ran at all. Same failure shape as #273: the gate looks fine and is doing nothing.Workaround used on #187
Closing and reopening the PR.
build.ymlandapi-diff.ymlboth listreopenedin theirpull_requesttypes:, so the full matrix runs and the required contexts report. It does not touch the branch or the release content.That works, but it is a manual step someone has to know about on every release, and if they do not know it, the release PR simply sits there looking blocked. Which is how #273 went unnoticed for two weeks.
Options
GITHUB_TOKEN. Pushes from a non-GITHUB_TOKENidentity do trigger workflows, so the release PR gets CI like any other. This is the documented release-plz recommendation and removes the manual step. Costs a secret to manage.CLAUDE.mdand accept it. Free, but relies on the human remembering.Cargo.lock, which is exactly the input the wire-compat gate exists to watch.Option 1 is the real fix. Option 2 is worth doing regardless, because until the token changes, anyone looking at a stuck release PR needs to know why.
Related: #273 (the last time a release-pipeline failure was invisible), #275 (the guard for that one). Part of the "fail closed, fail loud" line in #247.