.github: Pypi release workflows #737
Conversation
pdgendt
force-pushed
the
pypi-release
branch
from
a7f975e
to
17dd383
Compare
pdgendt
force-pushed
the
pypi-release
branch
from
17dd383
to
9cf14d2
Compare
Verify build for all major.minor versions from 3.8 till latest. Signed-off-by: Pieter De Gendt <[email protected]>
Add a package workflow with the latest python version to test creating a pypi release. Signed-off-by: Pieter De Gendt <[email protected]>
pdgendt
force-pushed
the
pypi-release
branch
from
9cf14d2
to
ce049ec
Compare
Upload a pypi package when a Github release is published. Signed-off-by: Pieter De Gendt <[email protected]>
Update section on creating Pypi releases. Signed-off-by: Pieter De Gendt <[email protected]>
| with: | ||
| files: dist/*.whl | ||
|
|
||
| - name: Publish package to PyPI |
There was a problem hiding this comment.
This last PyPI step depends only on the "Download" step, correct? Not on the gh-release step. It wasn't clear to me until I checked the documentation so maybe state that in a 1-line comment?
Actually, wait: shouldn't gh-release be last, after pypi-publish? What is its purpose, just a "backup" of the PyPI release, isn't it? In case of a failure/glitch, I think it's better to have the official PyPI release published without the backup rather than the opposite?
There was a problem hiding this comment.
It's the same file but the gh-release step attaches it to the GitHub release, instead of uploading it manually.
There was a problem hiding this comment.
I think you missed my point. I'll submit a follow-up PR.
There was a problem hiding this comment.
In case of a failure/glitch, I think it's better to have the official PyPI release published without the backup rather than the opposite?
In case of a failure/glitch, you can retrigger the workflow to ensure that the full release workflow completes.
Add Github workflows to create Pypi packages and upload to Pypi when a release is published.