ci: publish a uniquely versioned dev build to TestPyPI - #703
Open
eltociear wants to merge 1 commit into
Open
Conversation
TestPyPI permanently refuses a filename it has already accepted, so a manual run of this workflow -- where pyproject.toml still carries the version of the last release -- failed with "400 File already exists" (unitaryfoundation#350). Build a second, separately named copy for TestPyPI carrying a PEP 440 dev segment (.devYYYYMMDD<run_number>), and publish that instead. The release-dists artifact is untouched, so the build that reaches real PyPI is still the exact version that was tagged. Co-Authored-By: Claude Opus 5 (1M context) <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.
Fixes #350.
The problem
python-publish.ymlbuilds once and sends that same artifact to both TestPyPI and PyPI. On aworkflow_dispatchrun,pyproject.tomlstill carries the version of the last release, and TestPyPI never allows a filename to be reused:The change
release-buildnow produces a second artifact,testpypi-dists, built after appending a PEP 440 dev segment to the version, andtestpypi-publishuploads that instead:release-distsis built and uploaded first and is left untouched, so whatpypi-publishsends to real PyPI is still exactly the tagged version.Note on the suggested reference
@jordandsullivan suggested following mitiq's
publish-testpypi.yml, which appends the date directly to the version (\1${DATE}). Applied here that yields0.4.1220260729, which sorts above the real0.4.12release — a test build would look newer than the release it was testing. A.devNsegment sorts below the release instead, and is the "pre-release specific naming convention" the issue asks for.Out of scope
On
workflow_dispatchthepypi-publishjob also runs (github.event_name == 'workflow_dispatch' && github.ref == 'refs/heads/main') and would hit the same "file already exists" wall on real PyPI, since the release build deliberately keeps the unchanged version. Whether a manual dispatch should reach real PyPI at all felt like a maintainer call, so I have left that behaviour alone — happy to follow up if you would like it gated.Verification
The workflow YAML parses, and the version-rewrite step was run against the current
pyproject.toml: it producesversion = "0.4.12.dev<date><run>"and leaves every other line untouched (version =appears exactly once in the file). I could not exercise the workflow end to end, since that needs the repo'stestpypienvironment.🤖 Generated with Claude Code