Change PyPI publishing to trigger on releases and tags#187
Merged
Conversation
Updated both PyPI and TestPyPI workflows for controlled releases: PyPI (production): - Trigger: When a GitHub release is published - Use case: Official releases to PyPI - Process: Create release → Publish → Auto-deploy to PyPI TestPyPI (testing): - Trigger 1: When a release is created (draft) or marked as prerelease - Trigger 2: When pre-release tags are pushed (v*rc*, v*-dev*, v*-alpha*, v*-beta*) - Removed: PR to main trigger (no longer needed with new release process) Benefits: - Controlled release process tied to GitHub releases - Test pre-releases on TestPyPI before production - Prevents accidental publishes from direct commits - Supports standard pre-release versioning Workflow: 1. Test: git tag v0.8.1rc1 && git push --tags → TestPyPI 2. Draft: Create draft release → TestPyPI 3. Pre-release: Mark as prerelease → TestPyPI 4. Production: Publish release → PyPI Manual triggers via workflow_dispatch available for both.
bortok
added a commit
that referenced
this pull request
Jan 4, 2026
Makefile changes: - 'make test-publish' now creates and pushes pre-release tags - Automatically triggers GitHub Actions for TestPyPI publish - Validates version contains rc/dev/alpha/beta - No local build/upload needed - 'make pubdev' remains as legacy alias BUILD.md updates: - Document new automated 'make test-publish' workflow - Clarify manual vs automated publishing - Add Make commands reference section - Update workflow summary with new process - Remove confusion about manual upload New workflow: 1. hatch version rc → v0.8.1rc0 2. make test-publish → Creates tag, pushes, triggers GitHub Actions 3. GitHub Actions builds and publishes to TestPyPI This aligns with the tag-based publishing from PR #187.
3 tasks
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
This PR updates the PyPI and TestPyPI publishing workflows to use a more controlled release process based on GitHub releases and tags, instead of automatic publishing on every push to main.
Changes
PyPI Workflow (Production)
Before: Published to PyPI on every push to
mainbranchAfter: Publishes to PyPI only when a GitHub release is published
on.release.types = [published]TestPyPI Workflow (Testing)
Before: Published to TestPyPI on every PR to
mainAfter: Publishes to TestPyPI when:
on.release.types = [created])on.release.types = [prereleased])v*rc*,v*-dev*,v*-alpha*,v*-beta*)Removed: PR to main trigger (replaced with more intentional release triggers)
Benefits
Release Workflow
Testing a Pre-release
Publishing to Production
Manual Trigger (if needed)
Both workflows still support manual triggering via
workflow_dispatch.Breaking Changes
None - this only changes the automation triggers. Manual publishing via
make publishis unchanged.Testing