ci: manage releases with release-please - #36
Merged
Conversation
Replaces the hand-rolled release workflow. The previous attempts all failed on the same conflict: the version had to be decided somewhere, and every option either required CI to write to a branch its rulesets protect, or left package.json as a placeholder that no longer described the published package. release-please resolves both. It opens a release PR that bumps package.json, src/version.ts and CHANGELOG.md from the conventional commits on main. Merging that PR goes through the normal review path, so the ruleset is satisfied and the merge commit is signed by GitHub. release-please then tags it and creates the GitHub Release, and the publish job builds from that tag. The version in the repository is accurate again, and no tag or bump is created by hand.
While the version is below 1.0.0, features bump the patch and breaking changes bump the minor, matching how 0.0.2 through 0.0.5 were released — 0.0.5 itself carried a feat. Without this the next release would be 0.1.0.
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.
Supersedes #35. You were right that a placeholder version in
package.jsonis not how this is done — that was me working around the ruleset instead of using the flow the ruleset is designed for.Every previous attempt hit the same wall: something has to decide the version, and doing it in CI meant either writing to a branch that requires PRs, signed commits and passing code scanning, or leaving the repo's version describing nothing. release-please is the standard answer for a single npm package in exactly this setup, and this repo is already a good fit — conventional commits throughout, and a history of manual
chore: bump version to XPRs, which is the thing it automates.How it works now: merge PRs as usual; release-please maintains an open
chore(main): release x.y.zPR that bumpspackage.json,src/version.tsandCHANGELOG.md; merging that PR tags it, creates the GitHub Release, and triggers the publish job. Nothing is bumped or tagged by hand, and the merge goes through normal review so the rulesets are satisfied rather than bypassed.Before this can run:
v3.0.0(release was deleted, tag remains, pointing at current main),v0.0.6, and the typov0.05. The manifest pins the current version at0.0.5, so release-please will not be confused by the strayv1.0.x/v2.0.xtags, but they are still noise.What to look at:
.release-please-manifest.json— bootstrapped to0.0.5, matching npm's latest and the currentpackage.json. This, not the git tags, is what release-please reads. Getting it wrong means the next release lands on the wrong number.src/version.ts— the// x-release-please-versionmarker is what makes it bump alongsidepackage.json. Removing that comment silently breaks the sync;tests/version.test.tsis what catches it..github/workflows/release.yml—publishruns only onrelease_created, checks out the release tag rather than main, and keepsid-token: writescoped to that job.Verified:
bun run test(196 pass),vp checkclean, workflow YAML and both JSON files parse. The release-please run itself is unverified until this lands on main.🤖 Generated with Claude Code