Automate PyPI publishing and document the contribution and release process - #67
Merged
Merged
Conversation
…ocess Add a Publish workflow that runs when a GitHub release is published: it builds the source distribution and wheel, checks them with twine, installs the wheel and runs the test suite against it from outside the source tree, confirms that the package version matches the release tag and that pre-release versions are marked as such, and then uploads the files to PyPI with Trusted Publishing after approval in the protected "pypi" environment. Merging to main never publishes. The workflow can also be run manually as a build-only dry run. Replace the 2014 style guide in CONTRIBUTING.md with the contribution, versioning, release, PyPI, and conda-forge instructions used across UDST, adapted to this repository's layout. Bump the version to 1.9.dev2 and add a changelog entry.
Merged
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
Sets up the release mechanics ahead of the 1.9 release, following the pattern established in ChoiceModels 0.3 and UrbanSim 3.3 and tracked here in #63: a release PR goes to
main, av*tag and GitHub release trigger a build, verification, and upload to PyPI via Trusted Publishing, and merging tomainnever publishes..github/workflows/publish.yml(new, copied from UrbanSim's). Runs when a GitHub release is published, or manually as a build-only dry run.buildjob:python -m build,twine check --strict, installs the wheel, runs tests, and saves the distributions as an artifact.publishjob: uploads the artifact to PyPI withpypa/gh-action-pypi-publish.CONTRIBUTING.md: workflow updates.1.9.dev2, with a changelog entry.One-time setup before the first release
orcaproject: ownerUDST, repositoryorca, workflowpublish.yml, environmentpypi.pypienvironment with required reviewers (the maintainers who approve releases).Plan after merging
Release PR for
1.9rc1→ tagv1.9rc1→ GitHub pre-release → approve thepypideployment →pip install --pre orca==1.9rc1in a fresh environment. Then the same for1.9.