ci: open the Version Packages PR with a PAT so its required checks run - #1262
Conversation
`main` requires four checks — Build & canary release, Tests & lint, UI Tests and UI Review — all produced by pull-request.yml, which triggers only on `pull_request`. The changesets action was passed the default GITHUB_TOKEN, and GitHub deliberately does not fire `pull_request` events for PRs opened with that token (anti-recursion). So the Version Packages PR only ever collected the external checks (Bugbot, Vercel, snyk) and never the four required ones, leaving it permanently BLOCKED and mergeable only via admin override. Point the action at the existing UIKIT_GITHUB_TOKEN PAT so the PR is opened as a user and gets the normal PR workflows. The `Comment PR` step keeps the default GITHUB_TOKEN — it only posts a canary comment and needs no elevated identity. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
📦 NPM canary releaseDeployed canary version 0.0.0-canary-4ff5228. |
🧪 Storybook is successfully deployed!
|
🏋️ Size limit report
Click here if you want to find out what is changed in this build |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit aba9414. Configure here.
| commit: 'chore: release' | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| # Must be a PAT, not the default GITHUB_TOKEN. GitHub deliberately |
There was a problem hiding this comment.
Incomplete PAT for release PR
Medium Severity
The PAT is only passed to changesets/action, while actions/checkout still persists the default GITHUB_TOKEN in git extraheader. That header wins over later credentials, so Version Packages branch pushes stay attributed to the Actions bot. GitHub then suppresses pull_request synchronize runs, so required checks still fail to re-run when the release PR is updated and it can remain blocked.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit aba9414. Configure here.


Describe changes
Release PRs in this repo can only be merged with an admin override. This fixes the cause.
What's happening
main's protection requires four checks:All four originate from
pull-request.yml, which triggers onpull_requestonly.The changesets action in
publish.ymlwas passed the defaultGITHUB_TOKEN. GitHub deliberately does not firepull_requestevents for PRs opened with that token — it's an anti-recursion rule, so Actions can't trigger Actions indefinitely. The result is that a Version Packages PR collects only the external checks that don't depend on workflow events:So it sits at
mergeStateStatus: BLOCKEDforever. Confirmed on the currently-open #1259 and on the already-merged #1256, which shows the same four external checks and nothing else — meaning every release so far has been merged by overriding protection.Fix
Point the action at the existing
UIKIT_GITHUB_TOKENPAT, so the PR is opened as a user and receives the normal PR workflows. One line, plus a comment recording why it must not be reverted toGITHUB_TOKEN.The
Comment PRstep (line 99) intentionally keeps the default token — it only posts a canary comment and needs no elevated identity.Why not the alternatives
pushtrigger forchangeset-release/**would also emit the four context names without any credential, but it relies on Chromatic postingUI Tests/UI Reviewstatuses on a branch build rather than a PR build — less certain, and it makes the release PR behave unlike every other PR.mainfor every PR to solve a bot-PR problem.Follow-up needed after merge
The already-open #1259 was created by the old token, so it will not retroactively gain checks. To clear it: close #1259 and delete its
changeset-release/mainbranch — the nextPublishrun onmainrecreates it with the PAT, and it should then go green and merge without an override. I can do that once this lands.Two things I can't verify from here, worth a glance:
UIKIT_GITHUB_TOKENmust be unexpired withrepo+workflowscope. It was added 2024-06-13 and is currently referenced by no workflow, so I could not test it. If the next release PR is opened bygithub-actions[bot]rather than a user, the token is the reason.Checklist
Closes: N/A
Other information
No published output changes — this touches only how the release PR is opened.
🤖 Generated with Claude Code
Note
Low Risk
CI credential swap only; no runtime or package code changes, though release PR auth now depends on PAT validity and scopes.
Overview
Fixes release PRs stuck behind branch protection by having the changesets action authenticate with
secrets.UIKIT_GITHUB_TOKENinstead of the defaultGITHUB_TOKENwhen creating or updating the Version Packages PR.GitHub does not emit
pull_requestworkflows for PRs opened byGITHUB_TOKEN, so those release PRs never ran the four checksmainrequires (Build & canary release, Tests & lint, UI Tests, UI Review) and could only merge via admin override. A PAT opens the PR as a normal user PR so existingpull-request.ymljobs run.Adds an inline comment in
publish.ymldocumenting why this must stay a PAT. The canary Comment PR step is unchanged and still usesGITHUB_TOKEN.Reviewed by Cursor Bugbot for commit aba9414. Bugbot is set up for automated code reviews on this repo. Configure here.