Skip to content

fix(ci): build PyPI releases from the release tag - #665

Open
deanq wants to merge 1 commit into
mainfrom
deanq/publish-from-release-tag
Open

deanq wants to merge 1 commit into
mainfrom
deanq/publish-from-release-tag

Conversation

@deanq

@deanq deanq commented Oct 30, 2026

Copy link
Copy Markdown
Member

The 2.0.0 release went to PyPI as runpod 2.0.1.dev1, not 2.0.0.

What happened

Checked locally: setuptools_scm gives 2.0.0 at v2.0.0 and 2.0.1.dev1 at a4ba078.

Change

  • pypi-publish checks out needs.release-please.outputs.tag_name, so a release always builds from its tag.
  • A new tag input on workflow_dispatch lets a force publish build a given tag.
  • Without either, it falls back to the triggering commit, as before.

After merge

Publish 2.0.0 from its tag:

gh workflow run cd.yml -R runpod/runpod-python --ref main -f force_publish=true -f tag=v2.0.0

A PyPI maintainer should yank 2.0.1.dev1. pip skips .dev versions by default, so pip install runpod still resolves to 1.12.0 until 2.0.0 is published.

Test plan

  • Workflow YAML parses; checkout ref and the tag input are as listed
  • setuptools_scm version at v2.0.0 is 2.0.0
  • After merge: the dispatch run publishes runpod 2.0.0 to PyPI

🤖 Generated with Claude Code

The 2.0.0 release was tagged at the release PR's merge commit, but the
CD run that created it was triggered by the next push (#661). The
publish job checked out the triggering commit, so setuptools_scm
versioned the build 2.0.1.dev1 and that went to PyPI instead of 2.0.0.

Check out release-please's tag_name, or a new tag input when force
publishing by hand, and fall back to the triggering commit.

This branch was successfully deployed

1 active deployment
pypi-production — 3905010a Deployed Oct 30, 2026 by deanq via PyPI Publish #118
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant