MycroftAI/mycroft-messagebus-client

Automated PyPI Publication

NeonDaniel opened this issue · 3 comments

Is your feature request related to a problem? Please describe.
It looks like there is an automation for tagging releases on GitHub, but nothing for pushing new versions to PyPI.

Describe the solution you'd like
An automation to push to PyPI would ensure that merged changes are immediately available for use as dependencies in other Python packages. Versioning should already have been reviewed by the time a release is tagged and automation keeps releases in sync with PyPI.

Describe alternatives you've considered
Manual updates are always an option

Additional context
I have implemented this automation in several repositories, i.e.: https://github.com/NeonGeckoCom/neon-skill-utils/blob/dev/.github/workflows/publish_release.yml

There is a github action in place for that. it is triggered when the setup.py version is updated. (if I recall correctly)

Yeah, it's handled in this action:
https://github.com/MycroftAI/mycroft-messagebus-client/blob/master/.github/workflows/push.yml

We're bumping the version in the collect responses PR which will trigger a new release.

We don't currently do an automated increment of versions which I assume OVOS do for all the alpha's that get pushed out, but I'm personally not really sold on the value of that either.

We do want to standardize this across the organization, and I anticipate that we'll publish Github Actions for this purpose, rather than trying to keep files synced across all the repo's.

Edit: Closing as it exists, unless there's more that you think should be added?

There is a github action in place for that. it is triggered when the setup.py version is updated. (if I recall correctly)

Ah, I missed that as I was looking at the actions history and the last PR didn't trigger it because the version specified already existed.

We don't currently do an automated increment of versions which I assume OVOS do for all the alpha's that get pushed out, but I'm personally not really sold on the value of that either.

In Neon repos associated with PyPI packages, I keep a dev branch that will publish an alpha version on PR merge (auto-incremented) and a master branch that will publish a GH Release and PyPI package. The idea is that everything is approved into dev and when it's time to release, you just PR the version change to dev and merge to master

OVOS has manual triggers for versioning (unless something changed since I last looked). A repo owner/admin can trigger an action to bump the version spec and build/publish

Regardless of the methods, the advantage I see in publishing alphas regularly is that you can publish new features quickly without affecting stable systems and give devs some time to use previews as dependencies. It also means a PR to dev doesn't need to go through as much integration testing for backwards-compat. and can focus on the feature or bugfix the PR addresses.

Edit: Closing as it exists, unless there's more that you think should be added?

I think this issue is resolved