-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider dropping (the "required" state for) Travis? #395
Comments
Something odd is going on with our Travis-CI account:
(cc @ewdurbin) |
If we're fully ported to GitHub Actions, I don't see any reason to continue using Travis here (especially if we're consuming credits that other PyPA projects may actually need more than us). |
I'd say let's just take out Travis CI. |
I think the IRC integration is the only thing we are missing, otherwise we actually have integrated with GHA than Travis at this point. I have gone ahead and turned off the webhook to see how this goes. If it works out then we can delete the hook, |
Given that I have travis-ci muted in IRC, I don't think anyone cares about that integration at this point. :) Your plan sounds great to me! |
I've tweaked the status check requirements to only be GHA so that we control it while we see how this goes. I say we give it a month, and if it works out then we can drop Travis. |
Does anybody here have a clue what's happening with our Travis-CI account or if there's someone in charge of that account ? |
It looks like on Jan 29th, Travis switched us to a free plan with 10K build credits, but we're currently in a hole of -930 credits that we're not recovering from. I reached out to support. |
The PyPA travis account has been temporarily restored, but I'd still encourage this project (and others) to migrate to Actions. |
Thanks for the feedback @di pypa/manylinux & pypa/auditwheel could really benefit from travis-ci for |
@mayeut We're currently paying for a paid plan and waiting to see if we'll get renewed credits. The PSF is currently footing the bill but I think we can ensure that we don't pull the rug out from under pypa/manylinux and pypa/auditwheel as long as there isn't a better alternative. My encouragement is for projects like pypa/packaging that don't really need to be on Travis vs. another CI provider, and can help us reduce the overall Travis usage by migrating. |
Then I'm up for cutting off Travis now instead of waiting until the end of the month. |
At least we are the cheap one. 😉 |
Hmm... Is there something from pip still on Travis CI? Last I checked, every pip commit resulted in upto ~15 hours of machine time across our various workers across all platforms, so I'm not surprised that it's on top. |
@pradyunsg looks like yes: https://travis-ci.com/github/pypa/pip/builds |
So, drop Travis? |
Yup. |
OK, I think that's done! |
FYI: This got removed 2 months ago -- pypa/pip#9759 |
Personal experience with CPython says all CI fails, so you either don't require any of them or you stick with one and deal with its shortcomings rather than dealing with N tools' shortcomings.
Travis is currently not returning any status and since it's required I can't merge any PRs without an admin override. I'm personally fine just going with GitHub Actions as I don't think Travis adds much benefit. But if people want to keep it then can we consider changing the status check requirement for it?
The text was updated successfully, but these errors were encountered: