AppVeyor is now required to pass on PRs
I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.
Hi Brett,
Stability doesn't appear to be a problem, but we have much less parallelism on AppVeyor than we do on Travis-CI. This may make waiting times longer than they used to be.
Apparently 3.6 builds (and perhaps 2.7) trigger two sequential AppVeyor jobs: https://ci.appveyor.com/project/python/cpython/build/3.6build10551
Regards
Antoine.
Le 10/01/2018 à 21:45, Brett Cannon a écrit :
I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Mon, 15 Jan 2018 at 14:42 Antoine Pitrou antoine@python.org wrote:
Hi Brett,
Stability doesn't appear to be a problem, but we have much less parallelism on AppVeyor than we do on Travis-CI. This may make waiting times longer than they used to be.
Apparently 3.6 builds (and perhaps 2.7) trigger two sequential AppVeyor jobs: https://ci.appveyor.com/project/python/cpython/build/3.6build10551
If the wait times become an issue for anyone then let me know and we can re-evaluate the situation.
-Brett
Regards
Antoine.
Le 10/01/2018 à 21:45, Brett Cannon a écrit :
I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Python 3 runs builds against the old MSVC (14.0) and the current one (14.1). I’m happy to fully drop support for the older one and remove those builds, but there was a bit of push back when first proposed. (Both toolsets produce binary compatible outputs, but the newer one has better library/compiler support and we may break people who don’t want to upgrade if we use it.)
Top-posted from my Windows phone
From: Brett Cannon Sent: Tuesday, January 16, 2018 11:49 To: Antoine Pitrou Cc: python-committers Subject: Re: [python-committers] AppVeyor is now required to pass on PRs
On Mon, 15 Jan 2018 at 14:42 Antoine Pitrou antoine@python.org wrote:
Hi Brett,
Stability doesn't appear to be a problem, but we have much less parallelism on AppVeyor than we do on Travis-CI. This may make waiting times longer than they used to be.
Apparently 3.6 builds (and perhaps 2.7) trigger two sequential AppVeyor jobs: https://ci.appveyor.com/project/python/cpython/build/3.6build10551
If the wait times become an issue for anyone then let me know and we can re-evaluate the situation.
-Brett
Regards
Antoine.
Le 10/01/2018 à 21:45, Brett Cannon a écrit :
I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
FWIW two Appveyor Python builds recently failed (network errors while fetching external libraries):
https://ci.appveyor.com/project/python/cpython/build/3.7build10631 https://ci.appveyor.com/project/python/cpython/build/3.7build10636
Xavier
Hi,
AppVeyor usually takes between 30 min and 1 hour to check a PR, whereas Travis CI takes between 10 and 20 minutes (in average, ignoring rare cases when it's broken). AppVeyor queue is regulary busy.
Sometimes, I know that my PR is right, because the fix is obvious. Sometimes, the PR has no impact on Windows. In these cases, the slow AppVeyor CI can be annoying since it prevents me to merge a PR.
What do you think of making AppVeyor optional again? Careful core developers should wait for AppVeyor, except if they know that Windows doesn't matter for a specific PR.
Victor
2018-01-10 21:45 GMT+01:00 Brett Cannon brett@python.org:
I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Wed, 24 Jan 2018 at 10:12 Victor Stinner victor.stinner@gmail.com wrote:
Hi,
AppVeyor usually takes between 30 min and 1 hour to check a PR, whereas Travis CI takes between 10 and 20 minutes (in average, ignoring rare cases when it's broken). AppVeyor queue is regulary busy.
Sometimes, I know that my PR is right, because the fix is obvious. Sometimes, the PR has no impact on Windows. In these cases, the slow AppVeyor CI can be annoying since it prevents me to merge a PR.
What do you think of making AppVeyor optional again? Careful core developers should wait for AppVeyor, except if they know that Windows doesn't matter for a specific PR.
No one has spoken up so I guess everyone else is okay with the delay ATM. My worry with flipping it off and trusting ourselves this close to the beta is the last time I did that people didn't wait and we landed breaking changes. So unless other people speak up that the delay is a hindrance I'm inclined to leave it until we at least get past the beta.
-Brett
Victor
2018-01-10 21:45 GMT+01:00 Brett Cannon brett@python.org:
I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
I'm fine with the delay. I've been thinking to implement the bot that will remind us when all the CI has been completed. So we don't have to wait, and won't forget about it.
Currently miss-islington does this only for the backport PRs made by miss-islington. I think it'll be useful to do that on other PRs too. (yes I'm aware GitLab does this but we are on GitHub)
Mariatta Wijaya
Hi,
The best would be able to have a bot merging a pull request once tests pass and a core developer asked a merge. I'm not talking about the current approval using review, but something new, like adding a special comment like "Merge". Such comment would only merge if it's written by a core developer.
Each time I approve a backport PR created by miss-ilington with "LGTM, good bot", I hope secretly that the PR will be merged automatically once CI tests pass ;-)
Is it possible to write a bot which merges a PR?
Victor
2018-01-25 20:04 GMT+01:00 Mariatta Wijaya mariatta.wijaya@gmail.com:
I'm fine with the delay. I've been thinking to implement the bot that will remind us when all the CI has been completed. So we don't have to wait, and won't forget about it.
Currently miss-islington does this only for the backport PRs made by miss-islington. I think it'll be useful to do that on other PRs too. (yes I'm aware GitLab does this but we are on GitHub)
Mariatta Wijaya
Is it possible to write a bot which merges a PR?
Yes it is possible, and we sort of discussing the same thing in python-dev [1] :)
Each time I approve a backport PR created by miss-ilington with "LGTM,
good bot", I hope secretly that the PR will be merged automatically once CI tests pass ;-)
You should have filed a feature request! :D To make it happen, I'll need miss-islington be promoted and given write access to CPython. Currently miss-islington can't merge.
[1] https://mail.python.org/pipermail/python-dev/2018-January/151899.html
Mariatta Wijaya
On 1/25/2018 4:31 PM, Victor Stinner wrote:
Hi,
The best would be able to have a bot merging a pull request once tests pass and a core developer asked a merge. I'm not talking about the current approval using review, but something new, like adding a special comment like "Merge". Such comment would only merge if it's written by a core developer.
Each time I approve a backport PR created by miss-ilington with "LGTM, good bot", I hope secretly that the PR will be merged automatically once CI tests pass ;-)
Great idea. At this point, pressing the button is, for me at least, a formality.
tjr
On 26 January 2018 at 07:31, Victor Stinner victor.stinner@gmail.com wrote:
Each time I approve a backport PR created by miss-ilington with "LGTM, good bot", I hope secretly that the PR will be merged automatically once CI tests pass ;-)
Is it possible to write a bot which merges a PR?
The last time we looked at this, the main technical problem was that there wasn't a native way to pre-edit the commit message before hitting the "Squash & Merge" button, and emulating that capability via a formatted comment misses out on a lot of UI niceties.
So for a first pass, I think a comment from the bot saying "Approved PR ready for merge" and mentioning the committers that left approving reviews would be a good way to go (I know Sanyam had to ping me on a couple of issues because I'd approved them, but switched to doing something else because CI was still running, and then never got back to actually merge them).
Cheers, Nick.
On 1/25/2018 1:52 PM, Brett Cannon wrote:
On Wed, 24 Jan 2018 at 10:12 Victor Stinner <victor.stinner@gmail.com mailto:victor.stinner@gmail.com> wrote:
AppVeyor usually takes between 30 min and 1 hour to check a PR,
Yesterday, AppVeyor surprised me by finishing in about 6 minutes, handily beating Travis. I wonder whether this was a fluke, or if something changed somewhere. Or was it the luck of no backlog.
No one has spoken up so I guess everyone else is okay with the delay ATM. My worry with flipping it off and trusting ourselves this close to the beta is the last time I did that people didn't wait and we landed breaking changes. So unless other people speak up that the delay is a hindrance I'm inclined to leave it until we at least get past the beta.
Since I develop and test on Windows, I don't usually need the AppVeyor test*, but for patches developed on *nix, it is needed.
- Even then, there was one IDLE test change that interfered with another
test, only on Windows.
Terry
participants (8)
-
Antoine Pitrou -
Brett Cannon -
Mariatta Wijaya -
Nick Coghlan -
Steve Dower -
Terry Reedy -
Victor Stinner -
Xavier de Gaye