[python-committers] Travis & AppVeyor hidden on Github, scroll the invisible region to see them.

[Gregory P. Smith]

On Fri, May 18, 2018 at 9:45 AM Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/18/2018 12:25 AM, Gregory P. Smith wrote:
> > VSTS is clearly not yet a stable continuous integration platform.  It
> > needs to be made non-blocking, and AppVeyor and Travis need to be
> > brought back!
> >
> > Examples:
> > https://github.com/python/cpython/pull/6938#issuecomment-389908094
> >     Windows broke -
> > https://python.visualstudio.com/cpython/_build?buildId=522
> > https://github.com/python/cpython/pull/6939
> >     Linux broke -
> https://python.visualstudio.com/cpython/_build?buildId=523
>
> Travis and AppVeyor are there on both issues, and both can be merged --
> manually -- by pressing 'Squach and merge', even though not green.  The
> VSTS results are not blocking -- they are not marked as 'Required'.


Sorry! A combination of github UX flaws led me to misunderstand what I was
seeing. The things I wanted to see were still run, but they are not
displayed, so I assumed they were gone.  That plus the no green button made
me assume the new things that were displayed containing one red item were
all that there was to see and that they were blocking everything.

There is a hidden secret scrolling region when "show all checks" is active
on github instead of actually showing all.  It only shows five (read: not
the five I want).  The things I wanted to see were at the bottom and thus
not displayed as it puts the VSTS builds up top for some unknown to me
reason.

I am intentionally not merging those PRs yet as I referred to them from
several places as examples of this problem.

The
> problem is that miss-islington was not changed, and sees any VSTS
> failure as a status check failure and a reason to not do the automerge
> you requested by approving the change.
>

That at least we can fix until we trust VSTS to be reliable.  As is, the
more checkers we have to block on, the more likely anything flaky (either
infrastructure or tests+code itself) is to block any given change.

What do people think about teaching miss-islington how to re-launch
specific CI runs a few times to deflake failures? ("1 out of n passes
counts as a pass") - That requires compute resources, but when it is what
the human is going to need to do anyways... why not reduce the need and
just automate it the first couple of times? I don't know how feasible this
is for any given CI system we use today on CPython given the various ways
in which they operate.

-gps


>
> > This was on a documentation-only change.
> >
> > We cannot be changing to new PR-merge-blocking continuous integration
> > services at this point during a release cycle.  This is preventing
> > changes from making it in.
>
> What *is* blocking merges and making them painful at times are the
> haphazard failures of test_asyncio on the blocking bots, Travis and
> AppVeyor, at a rate as high as 1/4 of individual test runs.  See
> https://bugs.python.org/issue33531
> On one backport last night, I had to run Travis 4 times, which means I
> had to periodically monitor the backport instead of approve and forget.
> And then I had to manually merge.
>
> tjr
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/3757d1db/attachment.html>