search

pymc-labs / CausalPy

A Python package for causal inference in quasi-experimental settings
https://causalpy.readthedocs.io
Apache License 2.0
829 stars 53 forks source link

Auto release of CausalPy 0.2.3 to PyPI failed #315

Closed drbenvincent closed 2 months ago

drbenvincent commented 2 months ago

See here https://github.com/pymc-labs/CausalPy/actions/runs/8569317167

Tagging @anevolbap, @juanitorduz, @jpreszler as I won't be able to get to this until next week 😭

juanitorduz commented 2 months ago

Not this weekend 🙈😞. I'll try early next week (never release or deploy on Fridays 😅)

jpreszler commented 2 months ago

Based on a quick look, I think changing the download-artifact@v3 to V4 in the release yaml may fix things. The artifact is being uploaded with V4 and based on https:// github.com/actions/download-artifact there are breaking changes and mixing the two is problematic.

anevolbap commented 2 months ago

Based on a quick look, I think changing the download-artifact@v3 to V4 in the release yaml may fix things. The artifact is being uploaded with V4 and based on https:// github.com/actions/download-artifact there are breaking changes and mixing the two is problematic.

Agreed. The version mismatch arises from issue #310. It could be reverted, or we could simply update the version of download-artifact to V4. I can do either of the two.

drbenvincent commented 2 months ago

Agreed. The version mismatch arises from issue #310. It could be reverted, or we could simply update the version of download-artifact to V4. I can do either of the two.

Happy for you to take this on. It's outside my area of expertise.

anevolbap commented 2 months ago

@drbenvincent, there is an open PR (#316) that reverts the problematic changes and hopefully fixes the auto-release issues.

drbenvincent commented 2 months ago

@drbenvincent, there is an open PR (#316) that reverts the problematic changes and hopefully fixes the auto-release issues.

Great stuff. Thanks for the speedy response. In theory, if I merge this and manually trigger the release workflow, that should maybe upload 0.2.3 to pypi without having to do another version bump?

anevolbap commented 2 months ago

@drbenvincent, there is an open PR (#316) that reverts the problematic changes and hopefully fixes the auto-release issues.

Great stuff. Thanks for the speedy response. In theory, if I merge this and manually trigger the release workflow, that should maybe upload 0.2.3 to pypi without having to do another version bump?

Yes, if I understand correctly the details of the release workflow you are correct, there is no need for an extra version bump :crossed_fingers:

drbenvincent commented 2 months ago

Hmmm, re-ran the GitHub action, but that failed again

anevolbap commented 2 months ago

The step Build source distribution seems to still be using the older versions (e.g. checkout@v4 instead of v3), like it is cached. Is it possible to run it from scratch?

EDIT: the release is tied to the tag 0.2.3 and commit 9746996 which is previous to the last PR that reverts the bad changes (commit dbaa17b). I'm not familiar with release processes but seems a re-tagging is needed to include the last commit or simply a new tag bumping the version.

drbenvincent commented 2 months ago

I manually uploaded 0.2.3 to pypi. So the current version is now available to pip install :)