ci: mint short-lived App tokens instead of a static RELEASE_TOKEN - #3
Conversation
RELEASE_TOKEN had expired, and nothing surfaced it until the first push to main in months failed at checkout — taking the release with it. A PAT sitting in repo secrets has no expiry signal; it just stops working at whatever moment the next run happens to be. Both workflows now mint an installation token per run via the existing ourPLCC Release Bot, matching plcc-ng-devcontainer. The tokens last about an hour, so there is nothing long-lived left to rot. RELEASE_TOKEN is no longer referenced anywhere and can be deleted from the repo's secrets. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR updates the release and weekly-check GitHub Actions workflows to stop relying on a long-lived RELEASE_TOKEN secret and instead mint short-lived GitHub App installation tokens per run, reducing the risk of “silent secret rot” that only surfaces during a release.
Changes:
- Add a
actions/create-github-app-token@v3step to mint a per-run installation token. - Use the minted token for
actions/checkoutand for GitHub API operations (semantic-release/gh).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.github/workflows/release.yml |
Mints a GitHub App token and uses it for checkout and semantic-release instead of RELEASE_TOKEN. |
.github/workflows/check-plcc-release.yml |
Mints a GitHub App token and uses it for checkout and gh CLI calls instead of RELEASE_TOKEN. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Generate release bot token | ||
| id: app-token | ||
| uses: actions/create-github-app-token@v3 |
| - name: Generate release bot token | ||
| id: app-token | ||
| uses: actions/create-github-app-token@v3 | ||
| with: | ||
| app-id: ${{ secrets.APP_ID }} | ||
| private-key: ${{ secrets.APP_PRIVATE_KEY }} |
|
🐳 PR image built: To test manually, update |
Those permissions were granted for semantic-release and gh, both of which now authenticate with the App token. check-plcc-release needs no GITHUB_TOKEN scopes at all; release needs only packages:write, for the GHCR login. README still told maintainers to create a RELEASE_TOKEN and never mentioned APP_ID/APP_PRIVATE_KEY, so anyone setting this up from scratch would have configured the secret that just failed. Also corrects the commit convention: README claimed `feat!:` produces a major release. It does not. The Angular preset does not parse the `!` shorthand, so `feat!:` with no footer matches nothing and yields no release while the pipeline stays green. The BREAKING CHANGE footer is what triggers a major. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
🐳 PR image built: To test manually, update |
|
🎉 This PR is included in version 1.1.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
RELEASE_TOKEN had expired, and nothing surfaced it until the first push to main in months failed at checkout — taking the release with it. A PAT sitting in repo secrets has no expiry signal; it just stops working at whatever moment the next run happens to be.
Both workflows now mint an installation token per run via the existing ourPLCC Release Bot, matching plcc-ng-devcontainer. The tokens last about an hour, so there is nothing long-lived left to rot.
RELEASE_TOKEN is no longer referenced anywhere and can be deleted from the repo's secrets.