Uh oh!
There was an error while loading. Please reload this page.
Publish to PyPI when a merge to main changes the version - #92
Merged
Conversation
Releasing currently means publishing a GitHub Release by hand, which is easy to forget and easy to get wrong -- nothing connected the version in pyproject.toml to what was actually on PyPI. A merge to main that changes `version` in pyproject.toml is now the release trigger. Merges that leave the version alone do nothing, so the workflow only runs when there is something to release. Guards, because a PyPI version cannot be replaced once uploaded: - The version is compared against HEAD^, so only an actual bump publishes. - If a tag `v<version>` already exists the run skips with a warning, which covers re-runs and reverts. - The test matrix (3.11-3.13) now gates the release instead of merely running alongside it. After a successful upload the workflow tags the commit and opens a GitHub Release with the built artifacts attached, so the tag history matches PyPI. Creating that release with GITHUB_TOKEN does not re-trigger this workflow -- GitHub suppresses that to prevent recursion. Publishing a GitHub Release by hand still works as before, and still verifies that the tag matches pyproject.toml. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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 freeto 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.
Releasing currently means publishing a GitHub Release by hand, which is easy
to forget and easy to get wrong -- nothing connected the version in
pyproject.toml to what was actually on PyPI.
A merge to main that changes
versionin pyproject.toml is now the releasetrigger. Merges that leave the version alone do nothing, so the workflow only
runs when there is something to release.
Guards, because a PyPI version cannot be replaced once uploaded:
v<version>already exists the run skips with a warning, whichcovers re-runs and reverts.
alongside it.
After a successful upload the workflow tags the commit and opens a GitHub
Release with the built artifacts attached, so the tag history matches PyPI.
Creating that release with GITHUB_TOKEN does not re-trigger this workflow --
GitHub suppresses that to prevent recursion.
Publishing a GitHub Release by hand still works as before, and still verifies
that the tag matches pyproject.toml.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com