Repository navigation
ci(release): release with release-please and an approval step - #43
Merged
Merged
Conversation
release-please opens a "chore: release X.Y.Z" PR from the Conventional Commit titles on main. When that PR is merged, the release job waits for an approval in the "release" environment. Then it runs the checks, creates the tag and the GitHub release, and publishes to PyPI with trusted publishing. A commit-hygiene check validates PR titles, bodies, branch names and commit messages. The manual bump and release targets are removed.
…the attribution check A re-run after a partial release now finds its own tag and goes on to publish, instead of stopping. The notes config drops the label categories, so the notes keep the "What's Changed" heading. The attribution check matches attribution phrases only, so PRs about integrations can name those products. The write token reaches only the steps that call gh.
jonathan-zenrows
previously approved these changes
Oct 14, 2026
…e the release PR The checks and the build now run in their own read-only job, before the approval, and pass the packages as an artifact. The job that can mint a PyPI token runs no project code, and the approver approves a green run. The manifest leaves CODEOWNERS, because every release PR changes it and the release environment is already the approval gate. The commit check fails when it cannot read the commits, and allows PEP, RFC and HTTP numbers. DEVELOPMENT.md explains how to recover when the checks fail after the release PR is merged.
jonathan-zenrows
approved these changes
Oct 14, 2026
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
2 participants
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
Releases now come from release-please and an approval step. The manual bump and release targets are removed.
What changes for maintainers
fix,featandperfneed a lowercase scope, for examplefix(crawl): ....fix,feat,perfandrevertPRs lead to a release.docs,chore,test,ci,refactor,buildandstylePRs do not.pyproject.toml,src/zenrows/__version__.pyanduv.lock..github/andrelease-please-config.jsonneed a review from@ZenRows/prod-approvers. Any maintainer can merge the release PR.How a release works
After each merge to
main, release-please opens or updates the PRchore: release X.Y.Z.releaseenvironment.The checks and the build run first, in a job with read-only rights, so the approval waits on a green build. The workflow then creates the tag
vX.Y.Zand the GitHub release, and publishes to PyPI. If the version is already on PyPI, it skips the publish. To publish an existing tag again, run the Release workflow by hand with that tag.Notes
make bump,make releaseandscripts/bump_version.pyare removed.release.yml, so the PyPI trusted publisher does not change.