Travis CI is no longer mandatory on Python pull requests
Hi,
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.
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
Should we consider dropping Travis CI as a CI provider if it continues to be so flaky? Otherwise isn't it becoming just noise on a PR?
On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner <vstinner@python.org> wrote:
Hi,
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.
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/J... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner <vstinner@python.org> wrote:
Hi,
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.
We should simply mark the github actions "Tests / Ubuntu" CI as required.
If we wind up not liking the behavior we can go back on it while we work something else out. But it seems dangerous to not have any blocking Linux CI. Linux is our most important platform. With our dev sprint next week we'll discover if it gets in our way more often than helps rather quickly.
I cannot rightfully apply an automerge label to a code PR so long as we lack Linux CI to block a merge.
-gps
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/J... Code of Conduct: https://www.python.org/psf/codeofconduct/
We should simply mark the github actions "Tests / Ubuntu" CI as required.
+1 I completely agree with everything Gregory said.
On Fri, 16 Oct 2020 at 19:36, Gregory P. Smith <greg@krypto.org> wrote:
On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner <vstinner@python.org> wrote:
Hi,
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.
We should simply mark the github actions "Tests / Ubuntu" CI as required.
If we wind up not liking the behavior we can go back on it while we work something else out. But it seems dangerous to not have any blocking Linux CI. Linux is our most important platform. With our dev sprint next week we'll discover if it gets in our way more often than helps rather quickly.
I cannot rightfully apply an automerge label to a code PR so long as we lack Linux CI to block a merge.
-gps
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/J... Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/7... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Fri, Oct 16, 2020 at 11:58 AM Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
We should simply mark the github actions "Tests / Ubuntu" CI as required.
+1 I completely agree with everything Gregory said.
+1 from me as well.
-Brett
On Fri, 16 Oct 2020 at 19:36, Gregory P. Smith <greg@krypto.org> wrote:
On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner <vstinner@python.org> wrote:
Hi,
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.
We should simply mark the github actions "Tests / Ubuntu" CI as required.
If we wind up not liking the behavior we can go back on it while we work something else out. But it seems dangerous to not have any blocking Linux CI. Linux is our most important platform. With our dev sprint next week we'll discover if it gets in our way more often than helps rather quickly.
I cannot rightfully apply an automerge label to a code PR so long as we lack Linux CI to block a merge.
-gps
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/J... Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/7... Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/P... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Fri, Oct 16, 2020 at 12:26 PM Brett Cannon <brett@python.org> wrote:
On Fri, Oct 16, 2020 at 11:58 AM Pablo Galindo Salgado < pablogsal@gmail.com> wrote:
We should simply mark the github actions "Tests / Ubuntu" CI as required.
+1 I completely agree with everything Gregory said.
+1 from me as well.
+1 vote too.
If Github Actions were perceived to be too slow or there are some limitations, I am willing to help experiment with a different CI system for Linux builds.
Thank you!
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!
//arry/
On 10/16/20 1:41 AM, Victor Stinner wrote:
Hi,
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.
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
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.
Victor
Le sam. 17 oct. 2020 à 19:58, Larry Hastings <larry@hastings.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!
/arry
On 10/16/20 1:41 AM, Victor Stinner wrote:
Hi,
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.
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
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 <vstinner@python.org> 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.
Victor
Le sam. 17 oct. 2020 à 19:58, Larry Hastings <larry@hastings.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!
/arry
On 10/16/20 1:41 AM, Victor Stinner wrote:
Hi,
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.
See https://github.com/python/core-workflow/issues/377 for the
discussion.
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.
Victor
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/Q...
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 -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Oct 18, 2020, at 15:45, Carol Willing <willingc@gmail.com> wrote:
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.
Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness.
-- Ned Deily nad@python.org -- []
On 10/18/20 1:18 PM, Ned Deily wrote:
On Oct 18, 2020, at 15:45, Carol Willing <willingc@gmail.com> wrote:
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.
Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness.
If we have something else set up to takes its place that's fine; otherwise, let's leave it up with the understanding that we have to check it manually for success or failure -- that's still valuable information.
On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On Oct 18, 2020, at 15:45, Carol Willing <willingc@gmail.com> wrote:
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.
Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running
On 10/18/20 1:18 PM, Ned Deily wrote: them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness.
If we have something else set up to takes its place that's fine; otherwise, let's leave it up with the understanding that we have to check it manually for success or failure -- that's still valuable information.
Unfortunately, the "valuable information" lately has been whether Travis is even working. 😉
-Brett
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/X... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Oct 19, 2020, at 13:59, Brett Cannon <brett@python.org> wrote:
On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 10/18/20 1:18 PM, Ned Deily wrote:
On Oct 18, 2020, at 15:45, Carol Willing <willingc@gmail.com> wrote:
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.
Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness.
If we have something else set up to takes its place that's fine; otherwise, let's leave it up with the understanding that we have to check it manually for success or failure -- that's still valuable information. Unfortunately, the "valuable information" lately has been whether Travis is even working. 😉
Yes, and I still think it's unfair of us to use so much of Travis's resources - resources that other projects could use - when we are almost entirely ignoring the results. On the master branch, each time a PR is merged or requires a CI run, we currently start up to 5 separate Travis jobs (some short-circuited but still jobs). The main job. which rebuilds python and runs the test suite, can run for 15+ minutes. And then backports run some of the jobs as well.
Let's just disable Travis on all branches for now until there is reason to believe the problems we've seen are fixed.
-- Ned Deily nad@python.org -- []
On Mon, Oct 19, 2020 at 11:22 AM Ned Deily <nad@python.org> wrote:
On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 10/18/20 1:18 PM, Ned Deily wrote:
On Oct 18, 2020, at 15:45, Carol Willing <willingc@gmail.com> wrote:
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.
Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running
On Oct 19, 2020, at 13:59, Brett Cannon <brett@python.org> wrote: them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness.
If we have something else set up to takes its place that's fine;
otherwise, let's leave it up with the understanding
that we have to check it manually for success or failure -- that's still valuable information. Unfortunately, the "valuable information" lately has been whether Travis is even working. 😉
Yes, and I still think it's unfair of us to use so much of Travis's resources - resources that other projects could use - when we are almost entirely ignoring the results. On the master branch, each time a PR is merged or requires a CI run, we currently start up to 5 separate Travis jobs (some short-circuited but still jobs). The main job. which rebuilds python and runs the test suite, can run for 15+ minutes. And then backports run some of the jobs as well.
Yep, if Travis has limited their free resources then we are wasting them. And without knowing where Travis gets their electricity there's even a potentially (very slight) ecological cost from us wasting the runs. I am with Ned about trying on to be wasteful here *just* *in case* Travs happens to find something in a CI run.
Let's just disable Travis on all branches for now until there is reason to believe the problems we've seen are fixed.
+1 from me.
-- Ned Deily nad@python.org -- []
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Oct 19, 2020, at 14:35, Brett Cannon <brett@python.org> wrote:
On Mon, Oct 19, 2020 at 11:22 AM Ned Deily <nad@python.org> wrote:
On Oct 19, 2020, at 13:59, Brett Cannon <brett@python.org> wrote:
On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 10/18/20 1:18 PM, Ned Deily wrote:
On Oct 18, 2020, at 15:45, Carol Willing <willingc@gmail.com> wrote:
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.
Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness.
If we have something else set up to takes its place that's fine; otherwise, let's leave it up with the understanding that we have to check it manually for success or failure -- that's still valuable information. Unfortunately, the "valuable information" lately has been whether Travis is even working. 😉 Yes, and I still think it's unfair of us to use so much of Travis's resources - resources that other projects could use - when we are almost entirely ignoring the results. On the master branch, each time a PR is merged or requires a CI run, we currently start up to 5 separate Travis jobs (some short-circuited but still jobs). The main job. which rebuilds python and runs the test suite, can run for 15+ minutes. And then backports run some of the jobs as well.
Yep, if Travis has limited their free resources then we are wasting them. And without knowing where Travis gets their electricity there's even a potentially (very slight) ecological cost from us wasting the runs. I am with Ned about trying on to be wasteful here just in case Travs happens to find something in a CI run.
Let's just disable Travis on all branches for now until there is reason to believe the problems we've seen are fixed. +1 from me.
Pablo, Łukasz: any objections to disabling Travis on your branches? If not, one of us, or Ernest, can just do it.
-- Ned Deily nad@python.org -- []
On 19 Oct 2020, at 21:22, Ned Deily <nad@python.org> wrote:
Let's just disable Travis on all branches for now until there is reason to believe the problems we've seen are fixed. +1 from me.
Pablo, Łukasz: any objections to disabling Travis on your branches? If not, one of us, or Ernest, can just do it.
Absolutely, go ahead. In fact I see somebody already did. Good. Faster backports FTW.
- Ł
Sorry for replying to an older thread. Travis has also limited their build minutes for open source projects as per new pricing plan : https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
Thanks
Regards, Karthikeyan S
On Fri, Oct 16, 2020, 2:12 PM Victor Stinner <vstinner@python.org> wrote:
Hi,
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.
See https://github.com/python/core-workflow/issues/377 for the discussion.
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/J... Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (11)
-
Brett Cannon -
Carol Willing -
Ethan Furman -
Gregory P. Smith -
Karthikeyan -
Larry Hastings -
Ned Deily -
Pablo Galindo Salgado -
Senthil Kumaran -
Victor Stinner -
Łukasz Langa