> Hi all,
> I had a long discussion with Steve at PyCon about VSTS. The benefits seem promising.
> Perhaps a reasonable step forward is to run Travis, AppVeyor, and VSTS as required for 3
> months or 6 months. This would give everyone a view into using VSTS.
But that isn't what happened.
Someone turned off our Travis and AppVeyor CI systems and made the unreliable VSTS system a PR merge blocker. :(
While we're in the middle of a release cycle!
Yep, and nothing has changed except we have added more CI; nothing else has changed.
> After the initial period, we could then revisit what makes sense in the longer term. Which
> could be to continue using and requiring all; use all but perhaps relax the requirement
> for passing; or to choose one preferred combination of tools.
That would be the only sane way to do this.
instead, we have:
both of which are entirely useless, providing zero information about what went wrong. and are clearly infrastructure failures. The UI has ZERO LOGS, and doesn't even link back to the github thing that triggered it.
for reference, those runs came from these issues:
Those PRs can't be merged into to 3.6 or 3.7 because of VSTS and whomever made the choice to hold the CPython repo hostage.
No, Travis and AppVeyor ran and they both say the PR passed. The issue is only that the Linux build on VSTS failed and miss-islington doesn't distinguish between required status checks and any status check. It can still be merged by clicking the "Squash and merge" button.
I am not impressed.
Bring back Travis and AppVeyor. Microsoft's currently alpha-quality toy must not be a merge blocker until after it has proven itself stable for at least a month. Even after that, if it continues to have a UI that doesn't put the logs up front and center when opening a failure, I will never want to open a link to it.
I'm going to choose to assume the tone used in this email is due to a misunderstanding of not noticing that Travis and AppVeyor are in fact still running and are required along with an oversight -- that I can take blame for if that's necessary -- that miss-islington doesn't distinguish between required and optional status checks when deciding whether to automatically merge. We can temporarily flip off VSTS if automatic merging is viewed as critical right now until after the RC, but otherwise all that has happened is we have introduced more CI which isn't as stable as Travis and AppVeyor yet due to working out testing kinks which did not come up when Steve was testing this on his fork of CPython (which we had to do for both Travis and AppVeyor as well).
But in the future, please give us the benefit of the doubt. I'm sitting in MSP trying to deal with this, stressed up the wazoo from worrying that somehow someone had changed something without speaking with me or a release manager, all while about to get on a plane after frankly being yelled at by a friend. :(