chore: release-please opens release PRs for the Go module and npm packages - #7
Merged
Merged
Conversation
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
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.
Summary
Replaces hand-tagging (Go) and hand-bumping (npm) with release-please, from the conventional-commit PR titles
pr-title.ymlalready enforces.release-please-config.json: the root Go module (tagsvX.Y.Z, no component prefix, ignorespackages/) andpackages/problem(tagsproblem-vX.Y.Z). Separate release PRs; breaking changes bump the minor while pre-1.0.release-please.ymlruns on pushes to canary withGITHUB_TOKEN. Canary requires reviews but no status checks, so PRs opened by that token, which don't trigger CI, can still merge. Package releases are kept off the "Latest" badge so the Go module keeps it.publish.ymlis unchanged in behavior: a release PR'spackage.jsonbump still triggers it.Anchors: release-please starts from the GitHub release matching each manifest version, so I created
v0.5.0(existing tag) andproblem-v0.1.0(the commit that set 0.1.0). Without them it would rebuild the changelog from all history.Testing
make checkchore(problem): release ...only ifpackages/problemchanged since 0.1.0, and achore: release 0.5.1/0.6.0PR once a fix/feat lands.Checklist
make checkpassespackages/problem/src/messages/(none changed)