chore: rename joerick/cibuildwheel -> pypa/cibuildwheel #682
Conversation
|
Going to wait until the CI points at the new repo to retrigger this. |
Did we get grandfathered into something? Or maybe you requested support since support from cibuildwheel helps them get customers, potentially? Etc. |
|
CircleCI have a Mac open source offering, but you have to email them to ask for it. I suppose I'll have to do the same on behalf of PyPA. Azure/Appveyor also needs sorting, getting late here so I'll have to pick that up tomorrow. |
|
Can we move to travis-ci.com? I've finally seen my first migration (https://travis-ci.org/github/scikit-build/cmake-python-distributions), so maybe there's a way to trigger that? |
Seems like the good time to do so. @joerick, I can try to trigger that if you want me to. |
|
I'd suggest avoiding Travis CI unless you want to regularly email them asking for "credits" to run jobs. |
|
FWIW, Github Actions provides 5 MacOS workers, so if all you need is a Mac VM, you might be able to use that. |
|
No, we test each CI system to make sure they all work - see the table https://github.com/pypa/cibuildwheel#usage. The point of the CircleCI job is to make sure we support CircleCI, not to make sure we support macOS (GHA covers all the main systems). I think it should be easy to request time from the systems, because if we support system X, then users are more likely to choose system X. We've had good success asking for allowance before, I believe. |
The PSF has been paying the pypa organization plan since February. According to @di in pypa/packaging#395 (comment), the plug won't be pulled as long as they're are no better alternative. Of course, the cibuildwheel usage is a bit different than the one of pypa/manylinux or pypa/auditwheel but given its purpose and as @henryiii exposed, I'd say it fits with the others (I also see pypa/warehouse is still using Travis CI, maybe the transition to GHA is not over yet or, better safe than sorry ?) |
|
I agree that cibuildwheel's usage of Travis is different than most our other projects and it makes sense to keep testing against Travis here. You should be able to on the PSF's plan now. The only reason Warehouse is still using Travis is because we haven't removed it yet. |
I think most open source projects are in this boat too. We previously discussed this in #653. I'm thinking the upcoming cibuildwheel 2.0 release would be a good time to drop support... would anyone be opposed to that? BTW, the .org shutdown is now scheduled for May 31st, just a week away. |
|
I don't like dropping support for Travis. It's still popular, it's still the best way to get alternate arches (~5x faster than emulation), and they have been pretty friendly toward open source if asked. Wheel building can be rare enough that you can fit within the free allowance. If someone doesn't like MS, then options are severely limited if you want to build all major platforms. And making sure we work on several systems helps us remain general. If we have to bend over backwards to support them, or if it becomes a financial burden (we are providing something for them, basically), then we can drop them. |
|
I think that if Travis were donating build time, that would be one thing. But as the PSF is paying, that does worry me a little bit - our CI usage is pretty heavy! Each build looks something like this:
Looking back over the build history, it's about 63 branch and 221 PR builds over the past 3 months. So roughly 95 builds per month = 125000 credits per month = $75 per month. This is probably an overestimate, because some builds were cancelled or failed early, but it's probably not too far off. Even if it's 50% of this, that's a bit concerning... |
|
That would be up to @di and/or others; I'd start by asking Travis about it, I'd like to give them a chance to keep support; I think they would get a net gain by having first-class support from cibuildwheel. |
|
I wonder if we can really limit the number of travis builds? Say making it only build on a "travisci" branch, and only syncing that branch every week or so? |
|
Maybe we could even generalize this - make a runci branch, sync weekly with a GHA job, and then only run GHA on PRs and master/main/1.x. Most problems should be caught by GHA, and the rare problems that kill other CI systems should hopefully be easy enough to pin down over a week's worth of changes. And, if you intentionally are changing something you think might break, you could always sync the runci branch sooner. |
Agreed. Apart from speed, there's also the occasional bug in qemu. I've seen this multiple times already.
Well, I do not agree with this. You can see reports by different (major) OpenSource projects that their requests for credits for OSS were ignored, denied or delayed.
The pypa plan is a 2 concurrent job plan for now so there are no credits involved. If credits were involved arm64, ppc64le & s390x would now be 0 credits with the introduction of "Partner Queue Solution" 2 weeks ago (announced by ARM but could not find an announcement by IBM nor TravisCI, their billing doc has been updated). |
Maybe, yeah. We did do some bodging around on Appveyor a while back too, when we had timeout errors - https://github.com/pypa/cibuildwheel/blob/master/appveyor.yml#L16 . But ideally, something without too much automation would be good. @mayeut's comment does change things a bit, though-
Ah, I see! I thought their pricing was all usage based. So this plan wouldn't cover mac builds, but would give us unlimited credits for the rest. That makes me a bit more comfortable.
Nice. So that makes continued testing of arm64, ppc64le (and s390x) a no-brainer - it genuinely is free for OSS. That leaves x86_64 Linux, Mac and Windows. Well, Mac is gonna cost us credits, we'd have to email them to ask for some OSS credit. Linux and Windows would be covered by the PyPA under the existing plan. Then we can continue to run Linux and Windows? Or drop it? I don't really mind too much. I'm inclined to drop the Mac support, repeatedly emailing and asking for credits doesn't seem all that fun... |
|
@mayeut The Travis CI app is installed on pypa/cibuildwheel. Any specific reason you've requested (multiple times now) for it to be installed on all repositories on pypa? |
|
@pradyunsg, activating it on cibuildwheel removed it from all other pypa repos... Edit: Message sent on the pypa-committers mailing list: https://mail.python.org/archives/list/[email protected]/thread/V3KCCAOKE2ITQNWC6GZM73WRRLRMKIVG/ |
|
Ah, fair! I approved the first one, and I've been confused since about all the other requests. :) |
|
The migration to travis-ci.com is done for cibuildwheel but builds are not starting with the reason "Owner pypa does not have enough credits.". I'm sending an email to travis-ci support to get this resolved. |
It also breaks all other builds if there are not enough credits only for macOS (the other builds being covered by the plan). |
Note that it still has joerick/cibuildwheel - confusingly it's still within my appveyor account, but this is the new project that points to the pypa github repo
YannickJadoul
force-pushed
the
henryiii/chore/renamepypa
branch
from
b7575c4 to
00aa455
Compare
|
Rebased. As macOS on CircleCI was temporarily disabled (#685), thing should turn green now. |
|
A bit late to the party, but for now Travis CI seems settled, then? So this could probably get merged, soonish? For what it's worth, my 2 cents: the alternative architectures are a good argument, but apart from that, if Travis is being annoying towards OSS (and us in particular), I don't really have an inclination to do any effort to keep supporting them. I'm not saying we should drop e.g. the |
I went through a few passes to enable that project, here's the latest.
@YannickJadoul, see also comments in #686 Maybe the way to go is to test only what would be free (& hassle-free, i.e. not begging for credits) in Travis CI so only alternative architectures. |
| [](https://ci.appveyor.com/project/joerick/cibuildwheel/branch/master) | ||
| [](https://circleci.com/gh/pypa/cibuildwheel) | ||
| [](https://dev.azure.com/joerick0429/cibuildwheel/_build/latest?definitionId=4&branchName=master) |
There was a problem hiding this comment.
It seems a bit odd that AppVeyor & Azure are still referencing your account.
I know it's working so that's just a minor remark but if you have a bit more insight on this, I'd like to learn something.
There was a problem hiding this comment.
Yeah, it's a little strange - I'm not sure how Appveyor is defining their data model, but it seems that I create a project within 'joerick' even though I link it with an org project. Azure seems even more disconnected, I create an Azure project, then tie it to any CI system, so you could also create an Azure project that's driven from the same codebase. The link from this project to each CI is defined by the Webhooks in Github, so that's where the definitive list of CIs on this project is stored - https://github.com/pypa/cibuildwheel/settings/hooks
There was a problem hiding this comment.
Thanks for the insight.
From the webhooks list you link to, gitlab seems to throw some errors. As it was working yesterday, should we consider this a temporary glitch and merge this or is there something more to look at ?
There was a problem hiding this comment.
I think it's fine to squash & merge, and I could start the backport to 1.x (which likely will also need some of the CI changes). If GitLab has issues we can open a new PR.
Yup, I don't mind #686 (comment) at all ;-) |
* chore: rename joerick/cibuildwheel -> pypa/cibuildwheel * Update Appveyor status badge markup Note that it still has joerick/cibuildwheel - confusingly it's still within my appveyor account, but this is the new project that points to the pypa github repo * Update Appveyor badge markup again I went through a few passes to enable that project, here's the latest. * Update Azure badge, also * Update Travis badge to reference the .com Co-authored-by: Joe Rickerby <[email protected]>
* chore: rename joerick/cibuildwheel -> pypa/cibuildwheel * Update Appveyor status badge markup Note that it still has joerick/cibuildwheel - confusingly it's still within my appveyor account, but this is the new project that points to the pypa github repo * Update Appveyor badge markup again I went through a few passes to enable that project, here's the latest. * Update Azure badge, also * Update Travis badge to reference the .com Co-authored-by: Joe Rickerby <[email protected]>
Doesn't change AppVeyor, might need to be special cased.