ci: restore PyPI publish and fix pbr version pin#317
Merged
Conversation
Commit f558acd ("Refine CI workflows to align with community practices") removed the publish-to-pypi and publish-to-testpypi jobs from publish.yml, leaving only build and github-release. Tag pushes have since built the distribution and cut a GitHub release without ever uploading to PyPI, so v2.3.4 and v2.4.0 are tagged and released on GitHub but absent from PyPI, where 2.3.3 (2025-07-02) is still the latest. Reported in #316. Restore both jobs, and make github-release depend on publish-to-pypi rather than build so a failed upload fails the release instead of passing silently. The TestPyPI job rebuilds instead of reusing the build artifact because pbr derives the version from git describe and needs full history to produce a unique .devN version; skip-existing keeps re-runs from failing on an already-uploaded version. Fixes #316 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.3.4 and 2.4.0 were tagged but never reached PyPI due to the removed publish jobs (see #316). 2.3.4's changes are a subset of 2.4.0's already listed here, so no separate entry is added; 2.4.1 will be the first PyPI release since 2.3.3 and carries all 2.4.0 changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
setup.cfg pins the last released version, so on untagged commits pbr derives the next patch version from git and errors: ValueError: git history requires a target version of 2.4.1, but target version is 2.4.0 Override with PBR_VERSION=<next>.dev<commit-count>, computed from the latest tag, so every untagged push builds a unique PEP 440-compliant dev release. Verified locally: PBR_VERSION=2.4.1.dev630 builds celery_redbeat-2.4.1.dev630. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
setup.cfg pinned `version = 2.4.0` in both [metadata] and [pbr], despite acf8261 introducing pbr specifically for dynamic git-tag-based versioning. pbr cross-checks any static pin against git history and errors once a commit lands after the tag it points to: ValueError: git history requires a target version of 2.4.1, but target version is 2.4.0 This broke every untagged build (e.g. the TestPyPI job), and was previously worked around with a PBR_VERSION override script rather than fixed at the source. Removing the pin lets pbr do what it's designed for: exact tag -> clean version (verified 2.4.0 at v2.4.0), untagged commit -> automatic <next>.devN (verified 2.4.1.dev5, N = commits since v2.4.0), both confirmed locally including under actions/checkout's default shallow fetch for the tag case. makefile no longer rewrites setup.cfg on release (git tag now IS the version of record); `make version` uses `python setup.py --version` to read it back through pbr instead of grepping a field that no longer exists. Co-Authored-By: Claude Opus 4.8 <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 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
publish-to-pypiandpublish-to-testpypijobs dropped by f558acd, which left onlybuildandgithub-release— tag pushes since then built and cut a GitHub release without ever uploading to PyPI.github-releasenow depends onpublish-to-pypiso a failed upload fails the release instead of passing silently.setup.cfgpinnedversion = 2.4.0in both[metadata]and[pbr], left over from before pbr was adopted for dynamic git-tag versioning. pbr cross-checks any pin against git history and errors once a commit lands past the tag it points to. Removed the pins so pbr derives the version natively — exact tag → clean version, untagged commit →X.Y.(Z+1).devN.make releaseno longer requiresVERSION=— it's auto-detected from the "X.Y.Z (unreleased)" heading at the top of CHANGES.txt (the value the previous release's post-release bump already wrote there), with an explicitVERSION='M.m.p'still accepted as an override.make versionreads the built version back viapython setup.py --version. Updated CLAUDE.md's documented release command to match.v2.3.4 and v2.4.0 are tagged and released on GitHub but were never published to PyPI, where 2.3.3 (2025-07-02) is still latest. Reported in #316.
Test plan
2.4.0; untagged commit builds2.4.1.devNbuild/publish-to-pypipath needs no fetch-depth changepublish-to-testpypisucceeded and uploadedcelery_redbeat-2.4.1.dev6to TestPyPI: https://test.pypi.org/project/celery-redbeat/2.4.1.dev6/make -n release-tagauto-detects VERSION=2.4.1 from CHANGES.txt and computes NEXT_VERSION=2.4.2;make -n release-tag VERSION=9.9.9confirms explicit override still winsv2.4.1tag push (make release), not exercised here sincepublish-to-pypionly runs on tag refsFixes #316
🤖 Generated with Claude Code