[Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?

[Erik Bray]

On Wed, Sep 5, 2018 at 4:32 PM Paul Moore <p.f.moore at gmail.com> wrote:
>
> On Wed, 5 Sep 2018 at 14:47, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> >
> > On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou <solipsis at pitrou.net> wrote:
> > > On Wed, 5 Sep 2018 11:03:48 +0100
> > > Paul Moore <p.f.moore at gmail.com> wrote:
> > > > On Wed, 5 Sep 2018 at 10:55, Victor Stinner <vstinner at 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