We've largely moved away from Travis for Jupyter testing in favor of Azure pipelines and CircleCI as Travis was becoming increasingly slow and timing out.
On Sun, Oct 18, 2020 at 11:03 AM Victor Stinner email@example.com wrote:
Sometimes, when you reschedule a build in Travis CI, a PR gets *two* Travis CI jobs instead of one, and the first one remains stale forever. There are multiple issues with Travis CI.
Le sam. 17 oct. 2020 à 19:58, Larry Hastings firstname.lastname@example.org a écrit :
I don't know how the configuration on this stuff works. But my dim
understanding is: some automation from Github (that we own / configure / wrote) notices that we have a new checkin on a PR and kicks off the Travis CI build. The problem is that sometimes the status of the Travis CI build doesn't get reported back.
It seems to me that this is a race condition. You don't usually lose
the race, and so usually everything is fine. But it's super frustrating on the rare occasion when you do lose the race, because you're stuck. You can't do anything to fix it.
But that itself suggests the solution--when a user loses the race, let
the user retry. If we simply had a "restart Travis CI job" button somewhere, I think that'd be a good-enough "Band-Aid" over the problem that we could live with it for a long long time. Long enough maybe for someone to fix the bug! Or for someone to replace Travis CI with something less race-condition-y!
On 10/16/20 1:41 AM, Victor Stinner wrote:
Python has no mandatory Linux CI job on pull requests anymore. Right now Windows (x64) remains the only mandatory job. Please be careful to manually check other CI before merging a PR.
We had to deal with at least 3 different issues on the Travis CI over the last 6 months. The latest one (3rd issue) is on the Travis CI side and is known for months. Sometimes, a Travis CI build completes but the GitHub pull request is never updated. Since Travis CI was mandatory, it was never possible to merge some pull requests. I also noticed a 4th bug, sometimes a PR gets *two* Travis CI jobs on a PR for the same Travis CI build, only one is updated, and so again, the PR cannot be merged.
For all these reasons, Travis CI was made optional.
I would be nice to have a mandatory Linux job: "Tests / Ubuntu (pull_request)" is a good candidate. But I didn't check if it's reliable or not.
Note: if someone manages to fix all Travis CI issues, we can reconsider making it mandatory again. But it seems like most people who tried (included me) are tired or bored by Travis CI.
python-committers mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at
Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ python-committers mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://email@example.com/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/