Skip to content

ci: adopt the fleet release-PR healer - #15

Open
forkwright wants to merge 1 commit into
mainfrom
ci/adopt-release-pr-checks
Open

ci: adopt the fleet release-PR healer#15
forkwright wants to merge 1 commit into
mainfrom
ci/adopt-release-pr-checks

Conversation

@forkwright

Copy link
Copy Markdown
Owner

Finding

Release PRs in this repo arrive with their required contexts absent rather than red.
release-please creates its PR with GITHUB_TOKEN, and GitHub raises no workflow-triggering
events for that token, so branch protection holds a PR with a missing context forever — nothing to
re-run, nothing to approve.

Evidence

Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733,
gnomon#68) sat 8 days at mergeStateStatus: BLOCKED with an emptystatusCheckRollup
while their workflow runs waited at action_required.

aletheia has carried the only healer for months. A file-existence check found
release-pr-checks.yml404 in all 17 other release-please repos, and nothing visible from
inside any of them revealed the gap.

Why this matters

A missing check is worse than a failing one. A red check advertises itself; an absent one looks
exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears
to be waiting on CI.

Desired correction

Adopt the reusable healer (forkwright/.github#56). This file asks for it and declares nothing
about how it works, so it cannot drift from the other adopters.

Done when: a subsequent release PR here reaches a non-empty statusCheckRollup without a human
approving runs by hand.

The permissions block is load-bearing

Not the usual boilerplate. For workflow_call the caller's permissions is a cap — a called
workflow can only downgrade the token, never upgrade it. A caller declaring the customary
contents: read alone would leave the healer unable to approve a single run, and the only symptom
would be a release that stayed stuck.

Proven, not assumed

The whole path was exercised on akroasis before this rollout:

  • Actions: write confirmed present in the reusable's job token, so the caller's grant does reach
    it (run 32982564877).
  • GITHUB_REPOSITORY resolves to the caller — the healer reported #465 at b75af1a6f,
    akroasis's own release PR, while running from forkwright/.github.
  • The workflow_run trigger fired automatically on release-please completion and superseded a
    manual dispatch via cancel-in-progress, exactly as designed.
  • GITHUB_TOKEN + actions: write approving a genuinely held run: 201, and the run moved
    action_requiredin_progress (probed on zetesis run 31286567826). No PAT and no repo
    secret are required
    — an assertion to the contrary lived unexamined in aletheia's copy for
    months and is false.

Release PRs here arrive with their required contexts absent rather than red:
release-please creates them with GITHUB_TOKEN and GitHub raises no
workflow-triggering events for that token, so branch protection holds a PR
with a missing context forever.
The healer lives in forkwright/.github; this file only asks for it.
The permissions block is load-bearing rather than boilerplate: for a called
workflow the caller's permissions are a CAP, never a default it may exceed, so
the customary `contents: read` alone would leave the healer unable to approve
a single run -- and the only symptom would be a release that stayed stuck.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@forkwright