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

Gregory P. Smith greg at krypto.org
Fri May 18 19:29:01 EDT 2018

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 testasyncio 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>

More information about the python-committers mailing list