This patch attempts to any remaining issues from #88, specifically
the mutliple runs (by specifying one one python version to build for)
and not requiring a 'click release button' step to be added to our
process. We may, in a future patch, decide to do more around the
github 'release' concept, which is separate from our current process
of doing a release to pypi when the project is tagged.
This patch also adds a push to the test instance of pypi for quicker
and more frequent verification that pulishing works as expected, and
to give us an easy way for new features to be tested by users between
official tags/releases.
This patch uses the github action built by pypa instead of twine
directly, as we did before, following official docs [1],[2].
This patch attempts to any remaining issues from #88, specifically the mutliple runs (by specifying one one python version to build for) and not requiring a 'click release button' step to be added to our process. We may, in a future patch, decide to do more around the github 'release' concept, which is separate from our current process of doing a release to pypi when the project is tagged.
This patch also adds a push to the test instance of pypi for quicker and more frequent verification that pulishing works as expected, and to give us an easy way for new features to be tested by users between official tags/releases.
This patch uses the github action built by pypa instead of twine directly, as we did before, following official docs [1],[2].
[1] https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ [2] https://github.com/pypa/gh-action-pypi-publish
Signed-off-by: Jason Guiditta jguiditt@redhat.com