Add a release workflow that publishes to GitHub and PyPI - #297
Merged
Merged
Conversation
mattjala
force-pushed
the
ci/release-workflow
branch
from
September 2, 2026 14:26
3191dc2 to
461ab05
Compare
h5pyd has been released and published to PyPI by hand - there is no release automation in the repo at all. Add a tag-driven workflow that builds the sdist and wheel once, checks the metadata, attaches them to a GitHub release, and then uploads them to PyPI via Trusted Publishing. PyPI is gated on the GitHub release rather than running alongside it. The two are not equally recoverable: a GitHub release can be deleted and recreated, while PyPI permanently burns a version number, so the irreversible half only runs once the recoverable half has succeeded. The version job resolves the version from pyproject.toml and fails if h5pyd/version.py disagrees, since version.py is what h5pyd.__version__ reports at runtime while pyproject.toml names the wheel. The build job re-checks this against the installed wheel so the two cannot drift onto PyPI. conda-forge is not driven from here; h5pyd-feedstock picks up new versions from PyPI on its own.
pyproject.toml declares 1.0.0 while version.py still said 0.24.0, and __init__.py re-exports version.py as h5pyd.__version__. A wheel built from master is therefore named h5pyd-1.0.0 but reports 0.24.0 once installed, so 'pip install h5pyd==1.0.0' yields a package that disagrees with itself. Bump version.py to match. This is also a prerequisite for the release workflow, whose version job fails while the two disagree.
Releasing required tagging by hand first, because the tag was the trigger. Derive it from pyproject.toml and create it in the workflow instead, so a release is one dispatch and the tag cannot disagree with the version it claims to be. The tag job sits after build and before github-release, keeping the pipeline ordered by how hard each step is to undo: validate and build create nothing, a tag and a release can be deleted, a PyPI upload cannot. A failed build therefore never leaves a stray tag behind. Re-running after a later job fails is expected, so an existing tag is a no-op when it already points at the commit being released and a hard error when it points somewhere else, rather than silently re-tagging. The push trigger is dropped: with the tag created here, pushing one by hand would no longer start a release, and leaving the trigger in place would offer a second path that behaves differently from the first. Note a tag pushed by the workflow could not have triggered it anyway - events raised with GITHUB_TOKEN do not start new workflow runs.
mattjala
force-pushed
the
ci/release-workflow
branch
from
September 2, 2026 17:22
e7f5836 to
09a7ff5
Compare
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.
No description provided.