feat: build windows distributions with cibuildwheel in GitHub CI

[2bndy5]

• resolves Release/Build process breaking consumers (wheels not available) #1341
• resolves ci: use cibuildwheel and GHA to build Windows wheels #1171
• resolves wheels for Windows are missing in release 1.12.2 #1222

This should avoid maintaining appveyor workflow (and free up appveyor account limitations 😉).

This also introduces windows aarch64 distributions 🎉

Lastly, I updated other spots in the GH actions workflow:

• upgrade actions/checkout to v5 (only breaking changes are internal like upgrade node version used for building their dist)
• turn off credential persistence in actions/checkout action (only useful if the workflow uses git push or similar)
• upgrade actions/download-artifact to v5 (only breaking changes are internal because this already uses merge-multiple: true)
• add job to check built distributions for non-tagged commits to default branch. This is meant to highlight any problems with dists' metadata before tagging a release.
• add job to build sdist (for sake of completeness)
• replace badge in README

Further Ideas

Ideas that are related to this.

These can be added to this PR with ease:

• remove the appveyor workflow (requires @jdavid to make necessary changes in appveyor first)
• use trusted publishing on PyPI (requires @jdavid to enable trusted publishing on PyPI first)
• automatically create a GitHub Release for each (new) tag pushed (using gh-cli)

These should be done in a separate PR:

• run tests with cibuildwheel
• satify Add SSH support on Windows platforms #994

[jdavid]

@2bndy5

remove the appveyor workflow (requires @jdavid to make necessary changes in appveyor first)

What I have to change in AppVeyor first? I will remove the project, but don't see why we cannot drop AppVeyor usage in pygit2 first.

[2bndy5]

I never used appveyor before. I was assuming that if the appveyor.yml was removed then, appveyor may throw some kind of error. Whatever works for you is good enough for me.

[2bndy5]

use trusted publishing on PyPI (requires @jdavid to enable trusted publishing on PyPI first)

I do have some experience here. If you decide to use trusted publishing (instead of using a long-lived API token), I would recommend leaving the "environment" field blank. It only complicates the needed CI workflow changes. Please ping me if/when you are ready to adopt trusted publishing.

[2bndy5]

automatically create a GitHub Release for each (new) tag pushed (using gh-cli)

This idea is not really necessary, but it would notify people (that are watching or have starred this repo) about new releases. Additionally, this idea can be used to generate a summary of commits since the last tag.

However, there are other ways to auto-generate changelog entries. Personally, I enjoy git-cliff, but it works best with conventional-commit messages (or GitHub PR labels).

[jdavid]

you were right, it produced an error in appveyor; anyway, I have removed both appveyor in pygit2 and the pygit2 project in appveyor, thanks!

[2bndy5]

I'm playing around more with cibuildwheel. Trying to get it to run tests for each build (even the ones obsoleted by abi3 builds). So far, there is no problems if the following snippet is commented out:

pygit2/test/conftest.py

Lines 25 to 28 in e5620b9

	# Fix tests running in Windows
	# XXX Still needed now we have moved to GitHub CI?
	if platform.system() == 'Windows':
	pygit2.option(pygit2.enums.Option.SET_OWNER_VALIDATION, False)

Although I am getting the ModuleNotFoundError: No module named 'pygit2._pygit2' error for non-abi3 builds... Still investigating.