Skip to content

Require AppVeyor to pass #41

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brettcannon opened this issue Mar 14, 2017 · 12 comments
Closed

Require AppVeyor to pass #41

brettcannon opened this issue Mar 14, 2017 · 12 comments
Assignees
Labels

Comments

@brettcannon
Copy link
Member

Not sure if we consider it stable enough, but it would be nice to have as a goal to make https://ci.appveyor.com/project/python/cpython be required just like we do for Travis.

@zware do you think this is ready to be flipped on? And is it fast enough?

@zware
Copy link
Member

zware commented Mar 14, 2017

I think it's stable at this point. The last several builds have all been green except for legitimate failures. I also flipped the option for 'rolling builds', which cancels an in-progress build if another commit comes in on the branch, which should help any speed issues.

I haven't been paying close enough attention to tell whether it's fast enough, but in my limited experience AppVeyor has always finished faster than Travis if Travis was doing a full build.

@zware
Copy link
Member

zware commented Mar 14, 2017

I say that, and then test_site fails again: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.416

@brettcannon
Copy link
Member Author

That's a persnickety failure that keeps popping up. I think once that test failure is dealt with we can flip on the gating.

@zware
Copy link
Member

zware commented Mar 14, 2017

I thought I had dealt with it with python/cpython#624.

@brettcannon
Copy link
Member Author

Is AppVeyor stable enough to turn this on as a requirement, @zware?

@brettcannon brettcannon added the CI label Apr 10, 2017
@orsenthil
Copy link
Member

orsenthil commented Apr 11, 2017 via email

@zware
Copy link
Member

zware commented Apr 11, 2017

@orsenthil You're referring to python/cpython#997? I've not seen that failure before. A fairly simple way to force a re-run is to make some bogus commit, revert it, and push it; then you can either reset the branch back to the last 'real' commit and force-push it, or just remember to remove the bogus commits from the summary when you do the squash-merge (which should be done anyway :) ).

I've just looked through all of the failing builds from the past 9 days, and they all appear to be legitimate (aside from the build for the above-linked PR). I think it's probably good enough to turn on, and reevaluate if there are complaints. I also still have python/cpython#954 open; it may or may not improve the situation in test_site, which is historically the most flakey test on AppVeyor.

@pfmoore
Copy link
Member

pfmoore commented Apr 11, 2017

@zware I believe that a simpler approach to re-trigger CI is to close and reopen the PR.

@brettcannon brettcannon self-assigned this Apr 11, 2017
@brettcannon
Copy link
Member Author

With python/cpython@7a99625 and python/cpython@523776c having just landed, I want to see if we can go a week without failures due to AppVeyor itself (people breaking Windows is another thing entirely). If we can go a week then I will flip on AppVeyor as required.

@brettcannon
Copy link
Member Author

So, is this something we want to flip on now?

@zware
Copy link
Member

zware commented Jan 10, 2018

I think so; I think it's been relatively stable lately, and if it causes problems we can always switch it back off.

@brettcannon
Copy link
Member Author

Done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants