chore: migrate from release-please to semantic-release#78
chore: migrate from release-please to semantic-release#78frankieyan wants to merge 9 commits intomainfrom
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
doistbot
left a comment
doistbot
left a comment
There was a problem hiding this comment.
This pull request smoothly transitions the repository's release pipeline from release-please to semantic-release, streamlining the process into a single automated workflow upon merging to the main branch. The new approach significantly reduces manual steps and standardizes our release automation with other non-product repositories. A few adjustments are noted for the release workflow configuration, particularly regarding npm provenance compatibility with GitHub Packages, ensuring the necessary npm version is available for OIDC publishing, refining timing for the publish success flag, and tightening workflow permissions to align with the principle of least privilege.
| # Enable the use of GitHub Packages registry | ||
| packages: write | ||
| # Enable semantic-release to publish a GitHub release and push commits | ||
| contents: write |
There was a problem hiding this comment.
[P2] Overly broad workflow permissions (Least Privilege)
The workflow-level GITHUB_TOKEN does not need contents: write, issues: write, or pull-requests: write because the semantic-release step explicitly authenticates via the App Token (GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}) to bypass branch protection rules.
Granting these write permissions to the built-in token violates the principle of least privilege. The workflow token only needs id-token: write (for npm OIDC), packages: write (for GitHub Packages publish), and contents: read (default/checkout). You can safely remove lines 13-18 and replace them with:
contents: readThere was a problem hiding this comment.
This follows the pattern set out by other repos (Typist, etc.), but we can bring this up in the thread.
…ility GitHub Packages doesn't support npm provenance, so having `provenance: true` in publishConfig would break the GitHub Packages publish step. Provenance for the npm registry is handled implicitly by @semantic-release/npm when the id-token: write permission is present, matching how typist handles this. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pull_request_target uses the workflow from the base branch, so the updated version never actually runs during the PR. The action only reads the PR title, so pull_request provides sufficient access. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3 participants
Overview
We're standardizing on semantic-release across our non-product repositories (ref). release-please required merging a separate release PR before publishing, adding latency and a manual step. semantic-release collapses this into a single pipeline: push to
maintriggers CI validation, version analysis, changelog update, npm + GitHub Packages publish, and a GitHub release.The setup follows Doist/typist as closely as possible, with three intentional differences:
mainonly (nonextprerelease branch), no CHANGELOG formatting step (Biome doesn't format Markdown), anddoist-release-botApp tokens instead of a PAT, adopted from todoist-sdk-typescript #529/#530.Reference
Pre-merge checklist
doist-release-botinstalled and added as bypass actor on both rulesetsDOIST_RELEASE_BOT_IDandDOIST_RELEASE_BOT_PRIVATE_KEYsecrets configuredv1.1.0pointing tointeraction-trace-v1.1.0)publish-package-release.ymlTest plan
Package Releaseworkflow runs on the merge commitchore:type)feat:orfix:commit tomain