Run CI on the "Version Packages" PR - #136
Merged
Merged
Conversation
GitHub suppresses `pull_request` events for anything done with the default GITHUB_TOKEN, to avoid workflows triggering themselves. The version PR that changesets opens is created that way, so it carried no CI at all: lint, typecheck, tests, e2e and the SDK package check were all skipped, and it merged to main unverified. That is benign while the PR only bumps a version and writes a CHANGELOG — which is all it does today — but nothing enforces that, and main is the branch that deploys and publishes. The workflow now mints a short-lived token from a GitHub App and uses it for both the checkout and changesets/action, so the PR comes from a distinct identity and the checks run. The App needs only Contents and Pull requests, both read/write. Both uses fall back to GITHUB_TOKEN when APP_ID is absent, so forks and any setup without the App keep releasing exactly as before — they just don't get CI on the version PR. Documented in CONTRIBUTING.
louisbels
added a commit
that referenced
this pull request
Jul 26, 2026
#136 left `release.yml` unparseable: `secrets` is not among the contexts available to a step-level `if`, so GitHub rejected the whole file. The failure is quiet — the run reports "failure" with **zero jobs**, and the workflow list shows the file path instead of its name. Releases would have stopped working silently at the next changeset. Resolving the secret at job level fixes it: `secrets` *is* available in `jobs.<id>.env`, and `env` is available to a step `if`. Added actionlint to the `check` chain, verified against the exact bug: release.yml:45:17: context "secrets" is not allowed here. available contexts are "env", "github", "inputs", "job", "matrix", "needs", "runner", "steps", "strategy", "vars" A broken workflow file is the one class of CI failure the CI itself cannot report, which is what made this worth a gate of its own rather than more care.
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 free
to 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.
The gap
GitHub suppresses
pull_requestevents for anything done with the defaultGITHUB_TOKEN, so workflows cannot trigger themselves. The "Version Packages" PR that changesets opens is created that way — so it carries no CI at all.You saw it on #135: 3 CodeQL checks, and nothing else. No lint, no typecheck, no tests, no e2e, no SDK package check. It merged to
main— the branch that deploys to production and publishes to npm — unverified.That is benign today, because the PR only bumps a version and writes a CHANGELOG. But nothing enforces that it stays that way.
The fix
release.ymlnow mints a short-lived token from a GitHub App and uses it for both the checkout andchangesets/action. The PR then comes from a distinct identity, and the checks run normally.The App needs exactly two repository permissions: Contents (read/write) and Pull requests (read/write).
Both uses fall back to
GITHUB_TOKENwhenAPP_IDis absent:So forks and any setup without the App keep releasing exactly as they do now — they simply don't get CI on the version PR. Nothing breaks if the secrets are missing or the App is uninstalled later.
Required configuration
This PR is inert until the two secrets exist. Setup is in
CONTRIBUTING.md; the short version:largerio/secret, generate a private keyAPP_IDandAPP_PRIVATE_KEYVerifying it worked
The next release cycle is the test: the "Version Packages" PR should show the full check suite instead of CodeQL alone, and be authored by the App rather than
github-actions[bot].Also note
@largerio/secret-sdk@1.1.0published cleanly from #134/#135. I pulled the tarball back from the registry to confirm: README and LICENSE present,exportsresolved throughpublishConfig, and zero imports of a private workspace package in the shipped.d.ts— the bug that made the previous release unusable from TypeScript.