On Wed, Sep 5, 2018 at 4:32 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 5 Sep 2018 at 14:47, Zachary Ware <zachary.ware+pydev@gmail.com> wrote:
On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 5 Sep 2018 11:03:48 +0100 Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 5 Sep 2018 at 10:55, Victor Stinner <vstinner@redhat.com> wrote:
Who ows the "python" AppVeyor project?
That seems to have fallen to me for the most part.
Can someone please give me the administrator permission on this project, so I will be able to invalid the build cache?
I don't appear to have admin rights on Appveyor either.
I've attempted to make a change that should give you both more access; even odds on whether it did anything :). I've never tried to use their REST API, so I don't know whether it will help with that at all.
I do indeed now seem to have admin access on Appveyor. Thanks for that. I guess I should therefore say that if anyone needs help with Appveyor stuff, feel free to ping me and save Zach from getting all the work :-)
For some reason it seems to be located in a hidden directory (".github/appveyor.yml"). Not the most intuitive decision IMHO. Travis' own config file ".travis.yml" is still at repository root, which makes things more confusing.
The idea there was to avoid proliferation of root-level dotfiles where possible, but if we would rather keep it at the project root it's a relatively simple change to make.
When working via github on the web (which I was) rather than on a local checkout where I can search, putting it in a subdiretory is a bit less discoverable (made worse because there's nothing about the name ".github" that suggests it would have Appveyor files in it :-)) I'd prefer it at the top level - but not enough to submit a PR for that at the moment, so I'm fine with it staying where it is.
For the actual issue at hand, the problem arises from doing builds on 3.6 with both the VS2015 and VS2017 images. Apparently something built in `/externals` by the VS2015 build gets cached, which then breaks the VS2017 build; I haven't tracked down how exactly that is happening. I think the preferred solution is probably to just drop the VS2017 build on 3.6 on AppVeyor; VSTS runs on VS2017 and dropping one of the builds from 3.6 will make AppVeyor significantly quicker on that branch.
Nice catch. I'd agree, it's probably not worth having both (particularly as, if Victor says, we have buildbots for the one Appveyor doesn't cover - but even if we don't I think VSTS has it covered).
I presume you're suggesting keeping 2017 is so that we don't have stray 2015-built artifacts in the cache, which makes sense to me, and I have a mild preference for keeping the latest compiler, as that's likely the one that people will find easier to get. But 2015 is presumably the version the official 3.6 builds are made with, so there's an argument for keeping that one (although if we do that I guess we need to find a *different* way of fixing the cached artifact issue).
tl; dr; I'm inclined to agree with you that just using VS2017 on Appveyor is the simplest option.
Hello, Let me take this note as an opportunity to nag that I have a still open pull request to add testing of Python on Cygwin to the AppVeyor build, which in theory works quite well: https://github.com/python/cpython/pull/8463 So +1 for dropping one build configuration from AppVeyor if that will make it easier in the future to add this one :) However, Victor has asked that as a prerequisite to adding a Cygwin build to AppVeyor, we first have a relatively stable buildbot. I had thought maybe adding advisory CI on AppVeyor *first* would make getting a stable buildbot easier, but I can see the argument either way, so we have added said buildbot: https://buildbot.python.org/all/#/builders/164 Unfortunately, for the last ~120 builds it has been all but useless due to at least two small, but long outstanding issues preventing 3.7.x from building on Cygwin. Both of those issues have proposed fixes pending review, both of which have PRs linked to from my AppVeyor PR. If anyone is interested in having a look at those I'd appreciate it, thanks (one of them also got some review from Inada Naoki, but we didn't ever agree on some concrete action items for making the patch acceptable, and it has stalled again...) Best, E