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

[Paul Moore]

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.

Paul