feat: automate releases with release-please#4
Merged
Conversation
Replace the manual "tag + GitHub Release" flow with release-please, so version bumps, CHANGELOG, tagging, and PyPI publishing are all driven by Conventional Commit messages. - release.yml: on push to main, run release-please; when it cuts a release, build + Trusted-Publish to PyPI in the same run (avoids the GITHUB_TOKEN cross-workflow trigger limitation). - release-please-config.json + .release-please-manifest.json: simple release type, version sourced from src/senderkit/_version.py via an `x-release-please-version` annotation; manifest starts at 0.0.0 so the first release PR cuts 0.1.0. - CONTRIBUTING + PR template: document Conventional Commits and the automated release flow; changelog is now generated, not hand-edited. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. ℹ️ You can also turn on project coverage checks and project coverage reporting on Pull Request comment Thanks for integrating Codecov - We've got you covered ☂️ |
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.
Summary
Automates the entire release pipeline so version, changelog, tag, GitHub Release, and PyPI publish are all driven by Conventional Commit messages — fulfilling the request to automate version + release creation.
How it works
mainrun release-please, which maintains a standing release PR that bumpsVERSIONinsrc/senderkit/_version.pyand updatesCHANGELOG.mdfrom the commit history.vX.Y.Z, creates the GitHub Release, and — in the same workflow run — builds and Trusted-Publishes to PyPI.Keeping build/publish in the same run as release-please (gated on its
release_createdoutput) sidesteps the well-known limitation that releases created viaGITHUB_TOKENdon't trigger a separateon: releaseworkflow. No PAT required.Changes
release.yml— rewritten:push → release-please → (build → publish)-on-release. Verifies the built version matches the tag before publishing.release-please-config.json/.release-please-manifest.json—simplerelease type; version updated in_version.pyvia anx-release-please-versionannotation. Manifest starts at0.0.0so the first release PR cuts 0.1.0 (this PR'sfeat:commit drives that minor bump)._version.py— annotated; still the single source of truth (dynamic version regex unaffected, verified).CHANGELOG.mdis now generated, not hand-edited.Reviewer notes
python -m build→senderkit-0.1.0.One-time repo setup required (not in this PR)
release.yml+ environmentpypi(you confirmed this is configured).🤖 Generated with Claude Code