Add cibuildwheel deployment

[IAlibay]

Fixes #20

Changes made in this Pull Request:

PR Checklist

• Tests?
• Docs?
• CHANGELOG updated?
• Issue raised/referenced?

[codecov]

Codecov Report

Merging #22 (0d070ea) into main (bf22738) will not change coverage.
Report is 1 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files

[IAlibay]

This should do the trick, it'll need testing in an actual deployment though.

[ianmkenney]

I think this looks fine. Am I understanding correctly that we will be able to get the wheels on pull requests when tags are pushed? If so then definitely good to go!

[IAlibay]

So the intent here is that a tag will auto push to testpypi and a release will push to pypi, the PR trigger needs to be removed before we merge

[ianmkenney]

From this section, do we get the wheels in PRs where tags are pushed? For local testing and whatnot.

[IAlibay]

What do you mean by "in PRs"?

When you push tags the wheels will be uploaded to testpypi directly so you can pull them down and test as necessary. You'll also get the artifacts stored locally but that's the exact same thing as whatt's on testpypi (unless the testpypi upload failed).

[ianmkenney]

This is all fine. My question is if I make a PR and one of the commits has a tag of the 0.1.1-rc_* family, will the resulting wheel be sent to TestPyPI or is it just when the merge into main happens and we add a proper 0.1.1 tag? It seems from your explanation in the main thread that all of this CI is only relevant in the main branch though. It doesn't matter too much either way, I just want to know if there is any reason to add an rc tag inside of a PR or just wait until it's in main.

[ianmkenney]

Oh, oops, that's why you're removing the pull trigger.

[IAlibay]

To better explain how this work:

1. When you want to do a release you tie off all the necessary changelog etc..
2. You git push some tags based on the final state of the main branch
3. As soon as you push the tags, this CI action is triggered and it'll build all the wheels and upload them to testpypi
4. The action will then pull down the wheels from testpypi and test them
5. If everything returns green then you can go ahead and do a full release
6. Publish a github release and this CI action gets triggered again
7. This time it'll create all the wheels and upload them to PyPi
8. From there your release is done and you're good to go.

[ianmkenney]

Alright sounds good, I'm good to merge whenever then!