Repository navigation
fix(js): Make the GitHub release with a GitHub token - #19
Conversation
The registry token and the release token were the same input, so publishing to a registry whose token is not a GitHub token failed at the release step, after the package had already gone out.
Code Review Summary✨ This PR fixes 🚀 Key Improvements
📉 Regressions
💡 Minor Suggestions
|
![sourceant[bot]](https://avatars.githubusercontent.com/in/1161781?s=60&v=4){kind=small}
|
|
||
| All notable changes to these reusable actions are documented in this file. | ||
|
|
||
| ## [1.5.0] - 2026-09-20 |
There was a problem hiding this comment.
This is a consumer-visible behaviour change, not just a fix: callers that previously passed a GitHub PAT (or any non-registry identity) as token to create the release will now silently get the job token, and releases made with github.token do not trigger on: release workflows. Filing it only under ### Fixed hides that from anyone upgrading, and the version stays at a minor bump. Add a ### Changed section documenting both the migration path (token -> github_token) and the GITHUB_TOKEN-does-not-trigger-workflows caveat.
| ## [1.5.0] - 2026-09-20 | |
| ## [1.5.0] - 2026-09-20 | |
| ### Fixed | |
| - `js/publish` made its GitHub release with the registry token, so publishing to a registry | |
| whose token is not a GitHub token failed after the package was already published. The | |
| release now uses the job token, or `github_token` where a caller needs another. | |
| ### Changed | |
| - `token` is now optional and is only sent to the registry. Callers that passed a GitHub | |
| token as `token` in order to create the release must pass it as `github_token` instead. | |
| Releases created with the job token do not trigger `on: release` workflows. |
|
|
||
| Publishing to the public registry instead needs `registry`, `access`, and a | ||
| token for it: | ||
| token for it. `token` authenticates the registry, and the GitHub release is made |
There was a problem hiding this comment.
Now that the release uses github.token instead of a caller-supplied token, the calling workflow must grant contents: write — with the read-only default token these repos commonly get, softprops/action-gh-release will fail with a 403. That requirement previously came for free with the PAT and is exactly the kind of failure this change is meant to remove, so it needs to be stated next to the new github_token input.
| token for it. `token` authenticates the registry, and the GitHub release is made | |
| token for it. `token` authenticates the registry, and the GitHub release is made | |
| with the job token unless `github_token` says otherwise. Creating the release with | |
| the job token requires `permissions: contents: write` on the calling job: |
|
|
||
| Publishing to the public registry instead needs `registry`, `access`, and a | ||
| token for it: | ||
| token for it. `token` authenticates the registry, and the GitHub release is made |
There was a problem hiding this comment.
The release step now defaults to github.token, which only authorizes a release when the calling job grants contents: write. Callers who previously relied on a release-capable PAT passed through token (with no registry), or whose job uses the default read-only job token, will fail the Create GitHub Release step after the npm package has already been published. The documented contract should state the required permission alongside the new github_token override.
| token for it. `token` authenticates the registry, and the GitHub release is made | |
| +token for it. `token` authenticates the registry. The GitHub release is made with | |
| +the job token, so the calling job needs `permissions: contents: write` unless | |
| +`github_token` supplies another identity: |
| uses: softprops/action-gh-release@v2 | ||
| with: | ||
| token: ${{ inputs.token }} | ||
| token: ${{ inputs.github_token != '' && inputs.github_token || github.token }} |
There was a problem hiding this comment.
The != '' guard is redundant: inputs.github_token is only ever a string, and GitHub Actions || already selects the right-hand operand for the empty string. ${{ inputs.github_token || github.token }} is equivalent and reads as the intended fallback, reducing the chance of a future edit breaking the guard.
| token: ${{ inputs.github_token != '' && inputs.github_token || github.token }} | |
| + token: ${{ inputs.github_token || github.token }} |
|
|
||
| Publishing to the public registry instead needs `registry`, `access`, and a | ||
| token for it: | ||
| token for it. `token` authenticates the registry, and the GitHub release is made |
There was a problem hiding this comment.
Making the release with github.token shifts the permission requirement onto the calling job. github.token can only create a release when the job grants contents: write (the repository default is often read-only, and a composite action cannot set permissions itself). Callers that previously relied on a PAT passed as token will now regress with a 403 at the release step. The documentation should call this out next to the new fallback behavior.
| token for it. `token` authenticates the registry, and the GitHub release is made | |
| +token for it. `token` authenticates the registry, and the GitHub release is made | |
| +with the job token (which requires `contents: write` permission on the calling | |
| +job) unless `github_token` says otherwise: |
js/publishpassed one token to both the registry and the GitHub release. A callerpublishing to npmjs passes an npm token, so the release step fails on it, after the
package has already gone out.
The release now uses the job token.
github_tokenoverrides it where a caller needsanother identity.
tokenbecomes optional, since a registry that trusts the workflowneeds none.