Add GitHub Actions workflow for publishing to PyPI#196
Conversation
Use a separate workflow that doesn't run on pull requests. Builds the archives/wheels and pushes to test PyPI on pushes to the master branch and to PyPI proper on releases.
|
@hugovk @dopplershift I implemented a workflow similar to what Hugo suggested in #195. I set it up as a separate workflow since it's only really critical when we make a release and it would be hard to have a broken release if the master branch is passing all tests (unless the PyPI upload itself is broken, which would be caught by the test pypi upload). Does this seem sensible? I struggled with this decision quite a bit. The test releases seem to be working: https://test.pypi.org/project/pooch/#history I enabled the deploy on this branch to test PyPI for now but will remove it before merging. |
| run: twine check dist/* | ||
|
|
||
| - name: Publish to Test PyPI | ||
| if: success() |
There was a problem hiding this comment.
I think if: success() is the default.
There was a problem hiding this comment.
👍🏽 I thought so but just wanted to be safe
| - name: Publish to PyPI | ||
| # Only publish to PyPI when a release triggers the build | ||
| if: success() && github.event_name == 'release' | ||
| uses: pypa/gh-action-pypi-publish@bce3b74dbf8cc32833ffba9d15f83425c1a736e0 |
There was a problem hiding this comment.
Well that's paranoid...and not a bad idea.
There was a problem hiding this comment.
😆 yeah that blog post linked in that comment made my skin crawl
There was a problem hiding this comment.
|
TODO:
|
| name: PyPI | ||
| runs-on: ubuntu-latest | ||
| # Only publish from the origin repository, not forks | ||
| if: github.repository == 'fatiando/pooch' |
There was a problem hiding this comment.
Technically, you could rely on the fact that secrets.PYPI_TOKEN is only available on the original repo. If someone else put their own token as a secret on their fork, it would only work if it had permission on pypi.org. Just thinking out loud...
There was a problem hiding this comment.
Yeah, but that would mean that the workflow runs and raises an error for most contributors when they update their forks. I get really bothered by those red crosses...
|
In general this makes sense, but it's also the kind of things I never get right the first time. So hopefully the pushes to test.pypi.org work... |
|
🤞🏽 but it seems to work for test.pypi.org so far. I guess we might have to merge this and see. But if it works on test.pypi it should work on pypi, right? Why would something like this ever break unexpectedly? |
| ls -lh dist/ | ||
|
|
||
| - name: Check the archives | ||
| run: twine check dist/* |
There was a problem hiding this comment.
This is part of pypa/gh-action-pypi-publish by default:
https://github.com/pypa/gh-action-pypi-publish#disabling-metadata-verification
There was a problem hiding this comment.
Ah right. But then again, they also that we should be running this. Might just leave it since it takes a few seconds only.
Yep, sounds sensible. I have separate workflows for lint, test, and deploy. It also means if, say, there's some temporary network error which stops deploy, you can restart just the deploy workflow. |
|
@hugovk thanks for the comments!
Thanks for sharing that link to your tinytext project! It really cleared up some things for me.
That's what I figured. Plus, I'm super paranoid with the CI on master so the release should be safe (famous last words). |
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
|
Alright fingers crossed that this actually works 🤞🏽 |
Use a separate workflow that doesn't run on pull requests. Builds the
archives/wheels and pushes to test PyPI on pushes to the master branch
and to PyPI proper on releases.
Reminders:
make formatandmake checkto make sure the code follows the style guide.doc/api/index.rstand the base__init__.pyfile for the package.AUTHORS.mdfile (if you haven't already) in case you'd like to be listed as an author on the Zenodo archive of the next release.