ci: adopt the fleet release-PR healer - #472
Merged
Merged
Conversation
Release PRs here arrive with their required contexts absent rather than red, because release-please creates them with GITHUB_TOKEN and GitHub raises no workflow-triggering events for that token. #465 sat 8 days at BLOCKED with an empty statusCheckRollup while five runs waited at action_required. The healer lives in forkwright/.github; this file only asks for it. The permissions block is load-bearing rather than boilerplate: a called workflow can only DOWNGRADE the caller's token, never upgrade it, 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.
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finding
Release PRs here arrive with their required contexts absent rather than red, because
release-please creates them with
GITHUB_TOKENand GitHub raises no workflow-triggering eventsfor that token. Branch protection holds a PR with a missing context forever.
Evidence
#465 (
chore(main): release 0.6.2) sat 8 days atmergeStateStatus: BLOCKEDwith an emptystatusCheckRollupwhile five workflow runs waited ataction_required.gh api repos/forkwright/akroasis/actions/runs?status=action_requiredcurrently returns 51 held runs.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 still waiting on CI. Releases stop, and nothing surfaces the cause.
Desired correction
Adopt the reusable healer merged as
forkwright/.github#56. This file asks for it and declaresnothing about how it works, so it cannot drift from the other 17 repos that will carry it.
Done when: a subsequent release PR here reaches a non-empty
statusCheckRollupwithout ahuman approving runs by hand.
The permissions block is load-bearing
It is not the usual boilerplate. For
workflow_call, the caller'spermissionsis a cap — acalled workflow can only downgrade the token, never upgrade it. A caller declaring the customary
contents: readalone would leave the healer unable to approve a single run, and the only symptomwould be a release that stayed stuck.
actions: writeapproves the held runs;pull-requests: readfinds the release PR and its head SHA. Nothing here writes to a PR.Note
This is the first adopter, deliberately — akroasis is the only repo with an open stuck release PR
right now, so it is where the end-to-end path can actually be observed rather than assumed. The
remaining 17 follow once a run here is read.
Independent of this, #465 is also blocked by a real compile failure that #471 fixes; the two are
unrelated causes on the same PR.