AppVeyor queue length measures

["Uwe L. Korn" <uw...@xhochy.com>]

Hello,

as a heads-up, I have requested with INFRA [1] to enable the Rolling Builds feature [2] of AppVeyor. We never look at old commits and very often we look at our private AppVeyor instances, so these builds should not matter. In addition, I'll shortly provide a PR that activates the fast finish flag for our builds [3] so that failing CI entries are immediately stopped.

Another, more drastic measure would be to only build parts of the matrix on PRs (all on master). I hope that the Rolling Builds gives us an emptier queue but I'm not sure how this will evolve now that we also have Rust Windows builds. My feeling is that once we break AppVeyor, we break at least 50% of all CI entries. Thus a good selection of the entries that are tested should also catch 95% of all problems.

Uwe

[1] https://issues.apache.org/jira/browse/INFRA-16470
[2] https://www.appveyor.com/docs/build-configuration/#rolling-builds
[3] https://issues.apache.org/jira/browse/ARROW-2533

Re: AppVeyor queue length measures

[Antoine Pitrou <an...@python.org>]

Hi,

Le 01/05/2018 à 20:35, Uwe L. Korn a écrit :
> Hello,
> 
> as a heads-up, I have requested with INFRA [1] to enable the Rolling Builds feature [2] of AppVeyor. We never look at old commits and very often we look at our private AppVeyor instances, so these builds should not matter.

+1, sounds great!

> Another, more drastic measure would be to only build parts of the matrix on PRs (all on master).

You mean depending on the PR changes (that's ARROW-2516)?  Or a static
subpart of the matrix?

I wonder why we have NMake builds on the matrix.  Are they really
important to some people?  With Ninja + Visual Studio builds we should
already have quite good coverage.

Regards

Antoine.