Tag releases from CI, and document the flow - #111
Merged
Conversation
bump2version tags the commit it creates, which works when a release is bumped directly on main -- CONTRIBUTING's flow -- but not when the bump arrives as a PR: squash and rebase both produce a different commit, so the tag points at something that never reaches main. v3.0.0 dangles off a discarded branch commit for that reason, and v3.1.0 was never tagged at all, leaving setup.py's download_url for it broken. The publish job now creates the tag and a GitHub release from the version it just published, after PyPI succeeds, and skips if the release already exists so a re-run is harmless.
CONTRIBUTING told maintainers to bump on main and push tags, which no longer matches how releases actually happen (a bump PR) and produced the dangling v3.0.0 tag and the missing v3.1.0 one. Describes the branch + PR flow with --no-tag, notes that the merge commit message has to keep 'Bump version' for the publish job to fire, and keeps the bump-on-main variant for anyone who prefers it.
leandropineda
changed the title
b-Tomas
approved these changes
Jul 30, 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.
bump2versiontags the commit it creates. That works for the flow CONTRIBUTING described — bump onmain,git push --tags— but not for how releases actually happen here. Merge commits are disabled on this repo, so a bump arriving through a PR is squashed or rebased into a different commit, and the tag points at something that never reachesmain.The tag list shows both failure modes:
main?v3.1.0v3.0.0ee6fa8dv2.1.0f526fddmain, the old way)Neither broke publishing, since the job triggers on
contains(head_commit.message, 'Bump version')rather than on tags — butsetup.py'sdownload_urlfor v3.1.0 404s and there is no GitHub release for it.Workflow: the publish job now creates the tag and release from the version it just published, so it lands on the commit that actually shipped. Runs after PyPI succeeds, and skips when the release already exists so re-running a job is harmless. Needs
contents: write, added to that job alone. No tag-triggered workflows exist here, so creating a tag can't set off another publish.CONTRIBUTING: rewritten to the branch + PR flow with
--no-tag, including the bit that bites otherwise — the merge commit message has to keepBump versionfor the publish job to fire, and a squash merge takes the PR title. The bump-on-mainvariant is kept for anyone who prefers it, since the CI step is idempotent.After this merges, #110's bump tags itself.