ci: unblock refresh-lockfile self-heal from the action_required gate (BLO-24150, BLO-25515) - #1297
Conversation
…ed (BLO-24150) Co-Authored-By: Paperclip <noreply@paperclip.ing>
|
🔗 Paperclip issue: BLO-24150 |
1 similar comment
|
🔗 Paperclip issue: BLO-24150 |
![allyblockcast[bot]](https://avatars.githubusercontent.com/u/57363972?s=60&v=4){kind=small}
There was a problem hiding this comment.
Ally — Consolidated PR Review
Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 1cb5410
Critical Issues (0)
Important Issues (0)
Suggestions (0)
Strengths
- The alert is narrowly scoped to an unmerged self-heal PR with one or more
action_requiredruns on its exact head. actions: readis added at the job level, and the only side effect is a targeted PR comment after the existing merge attempt.
Recommended Action
- No Critical or Important issues found; the change is ready for normal CI validation.
|
Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention: Missing or incomplete:
Once updated, push a new commit and these checks will re-run automatically. — commitperclip |
|
Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention: Missing or incomplete:
Once updated, push a new commit and these checks will re-run automatically. — commitperclip |
There was a problem hiding this comment.
Ally — Consolidated PR Review
Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: ce4cb8d
Critical Issues (0)
Important Issues (0)
Suggestions (0)
Strengths
- The alert checks the self-heal PR's current head and only posts when a workflow run is genuinely awaiting human approval.
- The added
actions: readpermission is minimal and the alert runs after the existing direct-merge/auto-merge attempt.
Recommended Action
- No Critical or Important issues found; the change is ready for normal CI validation.
…515) GITHUB_TOKEN-authored pushes/PRs get their checks quarantined in action_required (or, per BLO-24150's later occurrences, never queued at all) now that the merge queue is the only merge path on master — the self-heal PR then waits on `verify`, which structurally can never report. Generate an installation token the same way commitperclip-review.yml already does and use it for the push, PR create, and PR merge steps, falling back to github.token when COMMITPERCLIP_KEY isn't provisioned. Also widen the stall alert (from #1297) to fire on zero recorded workflow runs, not just action_required — the shape BLO-24150's later occurrences actually took.
allyblockcast
Bot
changed the title
|
Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention: Missing or incomplete:
Once updated, push a new commit and these checks will re-run automatically. — commitperclip |
1 similar comment
|
Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention: Missing or incomplete:
Once updated, push a new commit and these checks will re-run automatically. — commitperclip |
Thinking Path
BLO-24150 cause 3: the
chore/refresh-lockfileself-heal PR's own CI runs sat in GitHub'saction_requiredstate (2026-07-21, 2026-08-10, ~2.5h) until a human clicked "Approve and run". While that was open, everypnpm install --frozen-lockfilejob onmaster, every PR, and every merge-queue entry kept failing. A self-healing loop with a manual gate in the middle is not self-healing.This PR started as a paging mitigation (post a loud comment on stall) and now also carries the actual fix, per CTO decision on BLO-25515: route
refresh-lockfile.yml's push/PR-create/PR-merge through the commitperclip GitHub App installation token instead of${{ github.token }}.The mechanism: GitHub deliberately does not trigger workflow runs from
GITHUB_TOKEN-authored pushes/PRs (a recursion guard). Once the merge queue became the only merge path onmaster(3ce1f5910, 2026-08-10T03:56Z), the workflow's directgh pr mergecan no longer bypass checks and falls through to--auto --squash, which then waits on a requiredverifycontext that structurally can never report. That is the indefinite stall — it is not an Actions approval policy, which is why no repo-admin action is needed. App-token-authored PRs run CI normally on this repo (this PR itself is the proof).COMMITPERCLIP_KEY/COMMITPERCLIP_APP_IDare already provisioned on Blockcast, confirmed via theGenerate commitperclip tokenstep succeeding on 6/6 recentcommitperclip-review.ymlruns.What Changed
Single file:
.github/workflows/refresh-lockfile.yml.node .github/scripts/get-bot-token.mjs(same recipe already used bycommitperclip-review.yml) and uses it forgit push,gh pr create, andgh pr merge. Gated onCOMMITPERCLIP_ENABLED: ${{ secrets.COMMITPERCLIP_KEY != '' }}so a fork without the key degrades togithub.tokenrather than failing the job. Addsactions: readpermission for the run-status query.x-access-tokenURL rather than theoriginremote.actions/checkoutbakesgithub.tokeninto that remote's stored credential, which would silently undo the point of settingGH_TOKEN— the token swap is ineffective without this.MERGED, posts a loud PR comment naming the mechanism instead of waiting silently.action_requiredones. Anaction_required-only detector would miss those entirely, so the alert fires on either shape.Verification
Verified:
pnpm install --frozen-lockfilesucceeds on this branch's tree (Lockfile is up to date, resolution step is skipped, e2e job log 2026-08-12T01:53Z)..github/scripts/get-bot-token.mjsexists on master andcommitperclip-review.yml's gated token step reportssuccess(notskipped) on 6/6 recent runs, so the credentials resolve on Blockcast.Not yet verifiable, by nature: the end-to-end assertion is that the next real lockfile drift produces a
chore/refresh-lockfilePR that reachesMERGEDwith zeroaction_requiredruns. That requires an actual drift event, so it is captured as the verifying signal below rather than claimed here. Do not read this PR merging as proof cause 3 is closed.Verifying signal:
gh api "repos/Blockcast/paperclip/actions/runs?head_sha=<next-refresh-lockfile-PR-head>" --jq '[.workflow_runs[]|select(.status=="action_required")]|length'→0on the next real occurrence.state: MERGEDwith no human approving its workflow runs (BLO-24150 acceptance criterion 3).Risks
GITHUB_TOKEN. It is masked via::add-mask::and confined to three steps. Blast radius is bounded to this workflow, which only ever commitspnpm-lock.yaml— the pre-existing "Fail on unexpected file changes" guard still runs ahead of the push.COMMITPERCLIP_KEYthe workflow falls back togithub.tokenand the original stall returns. That is deliberate (better than a hard failure) and is exactly why theaction_requiredbranch of the alert is retained rather than deleted.elsebranch explicitly reports "likely still mid-flight, not stalled" to avoid crying wolf.Model Used
claude-sonnet-5[1m].claude-opus-5[1m]— written to satisfy the commitperclip template gate, which was blockingreviewon a PR whose code was already complete. No code was changed in doing so; the head SHA is unmoved.Full evidence trail in gbrain at
paperclip/facts/refresh-lockfile-github-token-authorship-blocks-merge-queue. Issue: BLO-24150, BLO-25515.