Skip to content

fix(release): open the Version Packages PR with the repobuddy App token (v2 line) - #61

Merged
unional merged 1 commit into
v2.xfrom
fix/release-app-token-v2
Oct 11, 2026
Merged

unional merged 1 commit into
v2.xfrom
fix/release-app-token-v2

Conversation

@unional

@unional unional commented Oct 11, 2026

Copy link
Copy Markdown
Contributor

Why

A changesets "Version Packages" PR opened with the built-in GITHUB_TOKEN does not trigger on: pull_request workflows. It gets no checks and can only be merged with an admin bypass.

What

The v2-line counterpart of #60. Ports the pattern from clibuilder/.github's pnpm-release-changeset.yml (whose Version PRs are authored by app/repobuddy) to:

  • pnpm-release-changeset-oidc.yml: optional RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY secrets, an actions/create-github-app-token@v3 step gated on both, and the token passed to actions/checkout (token:) and to changesets/action@v2.0.0 (github-token:), each falling back to the built-in token. v2 ignores the GITHUB_TOKEN env var, so the github-token input is what carries it; the env line is kept and points at the same token.
  • README.md: both caller examples gain the two secrets: lines, and the trade-off note is rewritten. Consumers whose pull-request.yml carries branches-ignore: ['changeset-release/*'] still skip checks on the Version PR until they drop that filter.

The changesets/action version, its inputs, and the npm OIDC steps are unchanged. pnpm-release-changeset.yml uses the CI_GITHUB_TOKEN PAT, which already triggers checks, so it is not changed.

Validated with actionlint 1.7.7.

🤖 Generated with Claude Code

A PR opened with GITHUB_TOKEN does not trigger `on: pull_request` workflows,
so the Version Packages PR gets no checks and needs an admin bypass to merge.
The changesets workflows that used GITHUB_TOKEN now accept optional
RELEASE_APP_ID and RELEASE_APP_PRIVATE_KEY secrets, mint an app token when
both are set, and hand it to checkout and changesets/action. Without them they
fall back to the built-in token, as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: unional <homawong@gmail.com>
@changeset-bot

changeset-bot Bot commented Oct 11, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 0e5db8c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@mergify

mergify Bot commented Oct 11, 2026 •

Copy link
Copy Markdown

This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again.

@unional
unional merged commit fc434f7 into v2.x Oct 11, 2026
3 checks passed
unional added a commit that referenced this pull request Oct 11, 2026
…cret (v2 line) (#63)

* fix(release): start CI on the Version Packages PR without a stored secret (v2 line)

Replace the optional GitHub App token from #61 with a secretless dispatch.
GITHUB_TOKEN-caused events start no workflows, so the version PR got no
checks and stayed blocked on the required `code / all-checks`.
workflow_dispatch is the one event GITHUB_TOKEN may trigger, so after
changesets/action opens or updates the PR, the release job runs
`gh workflow run <ci-workflow> --ref changeset-release/<branch>`.

- Remove RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY, HAS_RELEASE_APP, the
  create-github-app-token step and the token fallbacks.
- Update the README caller example and adoption steps.
- Add a `ci-workflow` input (default pull-request.yml) and document
  `actions: write`; callers must grant it and add `workflow_dispatch:`
  to their CI workflow. A failed dispatch warns, never fails the release.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: unional <homawong@gmail.com>

* fix(release): do not declare actions: write in the reusable workflow

A called workflow cannot request a permission its caller did not grant;
the run fails at startup. Existing callers grant only id-token, contents
and pull-requests, so declaring actions: write would break every release.
The dispatch stays fail-soft: without the caller grant it 403s and warns,
now with a message that names the missing actions: write grant.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: unional <homawong@gmail.com>

---------

Signed-off-by: unional <homawong@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to 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