We already have a good workflow setup for publishing tests to TestPyPI: Make a PR, squash and merge, let the CI build, validate, and publish a test release to TestPyPI — all good. :+1: The question now that we have PyPI namespace rights is what is the workflow to publish to PyPI?
I would suggest two CD models:
The corner model (which I now think is how GitHub Actions assumed people would do things):
$ git checkout master && git pull # verify that you're on master and synced with GitHub
$ bump2version <part> # bump the version and create a commit and tag
$ git push origin master --tags # push the commit and the tag to GitHub, causing TestPyPI to publish
On the new page enter the tag you just pushed (e.g. v0.2.1) in the "Tag version" box and the "Release title" box (to make it easy unless you really want to get descriptive)
Enter any release notes and click "Publish release"
This then kicks of the publication CD workflow that will use the PyPI API key to publish.
This approach is more manual (and so has more room for mistakes) but is also clear if any part fails how and why.
The pyhf model:
This would use the workflow that @kratsg developed for pyhf which is heavily automated. New versions are still controlled bump2version, but the part level of the resulting tag is determined through a GitHub label that is applied to a PR (example: https://github.com/scikit-hep/pyhf/pull/1051). When that PR gets merged in, a GitHub bot will then run bump2version and push the commit and tag to GitHub and additionally trigger a release be build, verified, and deployed to PyPI. The devs then have to go and manually create a release on GitHub to trigger a Zenodo DOI for the release.
This approach is highly automated, but if you don't understand the whole workflow like @kratsg and I do (and we've both spent many hours in GitHub Actions) then it is probably very difficult to debug if anything ever goes wrong.
@dguest What is your preference here for which model of deployment I should setup? I'm happy to go more in depth on either workflow.
We already have a good workflow setup for publishing tests to TestPyPI: Make a PR, squash and merge, let the CI build, validate, and publish a test release to TestPyPI — all good. :+1: The question now that we have PyPI namespace rights is what is the workflow to publish to PyPI?
I would suggest two CD models:
cornermodel (which I now think is how GitHub Actions assumed people would do things):This follows the example that @dfm has setup in
cornerwith running the workflow onpublishedreleaseevents and then only running the publish to PyPI step on that conditions. To instigate this workflow one would do the following:masterrun:v0.2.1) in the "Tag version" box and the "Release title" box (to make it easy unless you really want to get descriptive)This approach is more manual (and so has more room for mistakes) but is also clear if any part fails how and why.
pyhfmodel:This would use the workflow that @kratsg developed for
pyhfwhich is heavily automated. New versions are still controlledbump2version, but thepartlevel of the resultingtagis determined through a GitHub label that is applied to a PR (example: https://github.com/scikit-hep/pyhf/pull/1051). When that PR gets merged in, a GitHub bot will then runbump2versionand push the commit and tag to GitHub and additionally trigger a release be build, verified, and deployed to PyPI. The devs then have to go and manually create a release on GitHub to trigger a Zenodo DOI for the release.This approach is highly automated, but if you don't understand the whole workflow like @kratsg and I do (and we've both spent many hours in GitHub Actions) then it is probably very difficult to debug if anything ever goes wrong.
@dguest What is your preference here for which model of deployment I should setup? I'm happy to go more in depth on either workflow.