[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-18 Thread Ethan Furman

On 10/18/20 1:18 PM, Ned Deily wrote:

On Oct 18, 2020, at 15:45, Carol Willing  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.

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/XAJE43CDSNJYMYJVQEZ7TSXB7FGW57YD/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-18 Thread Ned Deily
On Oct 18, 2020, at 15:45, Carol Willing  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
  n...@python.org -- []
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/ZUHXBNZYLGRT2JKPRC5PKHULHV6JIRBZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-18 Thread Carol Willing
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  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  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-le...@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/QTAXIPIBIURBYMALYSKMMNVUOT7IBGPU/
> > 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-le...@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/ACT5QH6UYL2F2MFMTRZKBYDKU5SLZ6JA/
> 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-le...@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/RLUHFXIOKFQO3AHXHCQHTS7WKTURNL5G/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-18 Thread Victor Stinner
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  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-le...@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/QTAXIPIBIURBYMALYSKMMNVUOT7IBGPU/
> 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-le...@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/ACT5QH6UYL2F2MFMTRZKBYDKU5SLZ6JA/
Code of Conduct: https://www.python.org/psf/codeofconduct/