kazoo
kazoo copied to clipboard
python-zk
chore: add packaging without publish to CI
Why is this needed?
CI currently does not exercise packaging for pypi.
Proposed Changes
- Add a github actions workflow to test packaging (except for a pypi publish)
Does this PR introduce any breaking change?
No.
At the moment, this appears to be failing on unrelated issues. See https://github.com/python-zk/kazoo/pull/691
I merged #691 (thank you for that!), so this is ready to be rebased / finish out...
Codecov Report
Patch coverage has no change and project coverage change: -0.08 :warning:
Comparison is base (
33c348b) 94.78% compared to head (9cf8322) 94.71%.
Additional details and impacted files
@@ Coverage Diff @@
## master #692 +/- ##
==========================================
- Coverage 94.78% 94.71% -0.08%
==========================================
Files 57 57
Lines 8339 8339
==========================================
- Hits 7904 7898 -6
- Misses 435 441 +6
see 5 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
@jeffwidman Re-thinking about this, it seems we should actually publish "dev" version to the TestPyPI repository (using a version name like X.Y.Z.dev+{short_commit_id} or anything else if someone has a better idea) so that every step are tested every time. It would require a little more changes like adding a new secret for the repo.
Concerning Python 3.11 vs Python 3.10, I agree this is something that we can change once we add a pipeline for the 3.11 version of Python (we "only" have testing for up to 3.10 right now).
On my side, even if it is not perfect, I am fine going forward with the current state of the PR and doing the changes I mentioned above in another PR unless, of course, @bringhurst is interested in doing it on his side.
I think it's probably ok to commit this as-is. It's not perfect, but it gets the job done.
it seems we should actually publish "dev" version to the TestPyPI repository
I was looking at the cookiecutter-hypermodern-python project to to get ideas on how to do that, but I haven't had time to really dig in. They seem to have a very nice setup.
https://github.com/cjolowicz/cookiecutter-hypermodern-python/tree/main/{{cookiecutter.project_name}}/.github/workflows
Totally fine to punt on publishing to TestPyPI and 3.11, but I'd really rather we didn't introduce more copy/paste when we don't need to... that just increases risk of divergence in the build steps down the line resulting in fake confidence that our packaging is correct.
AFAICT, it should be straightforward to wire up actions such that we've got one workflow that handles all builds, and then a second workflow takes the output from first and actually publishes it...