Travis CI Usage

[ewdurbin]

Just a check-in from the Python Software Foundation regarding the Travis-CI plan that supports s390x, ppc64le, Arm64, and AMD64 architecture builds for this project.

Travis-CI is going to be raising prices on their plans soon, so I'm verifying a few things to inform if we move from monthly-to-annual billing to delay the cost increase (at least for a year):

1. Is Travis-CI still required for this project's CI/build needs?
2. Does the project anticipate being able to move off of Travis-CI at any point, particularly before March 2026?

[henryiii]

We run on Travis CI to ensure cibuildwheel users can use Travis CI. It's really a service to Travis CI; testing on Travis means we can list Travis as a supported platform in our docs/README, enabling users to be confident that they can build wheels if they use (pay for) Travis CI.

I think manylinux (pypa/manylinux#1750) is the place where Travis CI is actually needed (to build special architectures).

[ewdurbin]

Thanks for this context, @henryiii!

[mayeut]

As mentioned in the manylinux issue, I'm moving the discussion here as a whole.

Now that GitHub Actions is providing aarch64 runners, manylinux / auditwheel / (& cibuildwheel through #2259) dropped the aarch64 AWS Graviton 2 offer from Travis CI that required actual credits (or an unlimited concurrency based plan such as the one currently provided by the PSF).

manylinux & auditwheel are now only using the partner-queue-solution which is sponsored by IBM and is provided with a 0 compute credit cost as long as there are some compute credits available in the plan.

auditwheel could drop Travis CI but manylinux can't.

Going to a usage based plan (which is $15/month) would better fit manylinux / auditwheel as those projects don't need compute credits & would benefit from the 80 concurrent jobs limit instead of now 1 concurrent job.

The usage of Travis CI by cibuildwheel is exactly as @henryiii said but I'll add that cibuildwheel is currently also using testing Linux x86_64 / Windows x86_64 which are paid for so going to a usage based plan would require cibuildwheel to reduce or remove testing on paid-for test axes in order to never go to negative credits which would block manylinux (the only project where it's really needed). Given the only project we do require credits is the one where it's more a service to Travis CI than the other way around, maybe some other specific solution could be worked with Travis CI.

In any case, I'll open a PR here to stop testing with Travis CI on pull requests as the 1 concurrent job limit is really delaying everything as of now and is mostly not very useful for cibuildwheel except for specific PR.