Move Mac and Linux builds to GitHub actions

[jamadden]

Since Travis CI no longer works. This is probably a blocker for any other PRs.

Because of the C extensions this doesn't quite fit our standard model.

I have some github actions YAML from other repos that deal with C extensions and building/uploading Mac/Linux[32-bit, 64-bit, aarch64] wheels that I can bring over as a starting point.

Someone with access to the zope.wheelbuilder account would need to add a repository secret for TWINE_PASSWORD (a token with scoped upload rights to zope.interface). (I could create a PyPI token from my personal account, but since we have a dedicated account I'd prefer not to.)

• [x] Environment that builds docs
• [x] 32-bit linux build/upload
• [x] 64-bit linux build/upload
• [x] aarch64 linux build/upload
• [x] coveralls
• [x] mac builds/upload
• [x] Pure-python tests
• [x] Compare other settings with existing "pure-python" configurations
• [x] Update badges
• [x] Update any docs references

[mgedmin]

Because of the C extensions this doesn't quite fit our standard model.

GitHub actions allows multiple workflow files. I wonder if life would be easier if we had one script-maintained standard .github/workflows/tests.yml, and another manually maintained .github/workflows/wheels.yml?

(Although eventually I suppose we'll want a template in the meta repo for all wheel-building ZF packages.)

Someone with access to the zope.wheelbuilder account

I'm one of those. I can do the thing, but I'd appreciate detailed instructions.

[jamadden]

I wonder if life would be easier if we had one script-maintained standard .github/workflows/tests.yml, and another manually maintained .github/workflows/wheels.yml?

I'm not sure about that. The tests need to be run on all the platforms that we distribute binary wheels for, but the standard tests.yml only runs them on one platform, so we're already diverging.

I have this tests.yml structured similarly to the way Travis allowed for build "phases": one phase builds the wheels, making them available for later phases. The later phases run tests, build docs, perform linting, etc. This is especially useful when the number of wheels built is a smaller number than the combination of the later phase jobs because you save the wheel building time, and you allow for increased parallelism. This repo isn't a great example because both building and running the tests are quite fast, but for something like BTrees where building takes non-negligible time, and testing takes substantial time, and the test matrix is larger than the number of wheels (there are special test cases for various configurations), it should be a net win. I found it to be so on RelStorage and gevent, at least.

Here, though, perhaps BTrees is the outlier and most projects with C wheels don't have complex builds or tests...

[jamadden]

Someone with access to the zope.wheelbuilder account

I'm one of those. I can do the thing, but I'd appreciate detailed instructions.

I'll see if I can help!

First, you'll need to create an API token that allows the zope.wheelbuilder account to upload to the zope.interface project. The basic steps to do that are outlined at https://pypi.org/help/#apitoken; basically you'll wind up at the token section of the account page for zope.wheelbuilder and you'll select Project: zope-interface in the 'Scope' dropdown (the name is for later reference only; it doesn't mean anything to PyPI or twine):

When you do that, the output will be a page with a long text string for the token. Save that token somewhere safe and secret, PyPI won't show it to you again.

Next, we need to use that token as the value of the github repository secret named TWINE_PASSWORD. To do that, come to this repository -> Settings -> Secret -> New repository secret and input the name and token value.

[mgedmin]

It is done:

[jamadden]

It is done:

Thanks!