Re: [appveyor] Really slow turnover

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2019-12-19 04:36:43

On Wed, Dec 18, 2019 at 9:28 PM Edward Diener via Boost <
boost_at_[hidden]> wrote:

> On 12/18/2019 9:37 PM, Rene Rivera via Boost wrote:
> > On Wed, Dec 18, 2019 at 6:20 PM Edward Diener via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> When I started out in computer programming some 40 years ago you could
> >> submit a job, with some JCL, on an IBM mainframe computer via an input
> >> card reader and you were lucky if you got back the result a day later.
> >> How happy I was when I went to microcomputers and could get almost
> >> instantaneous results from any programming attempt.
> >>
> >> Fast forward to now, some 40 years later, and it seems like nothing
> >> changes, despite the great advancement in computer technology and online
> >> access in our current age. Attempting to run CI using Appveyor literally
> >> has jobs queued pending a run for days and days. Surely there must be
> >> something better in this day and age than this ridiculously slow
> >> internet service. Is it 1979 again ?
> >>
> >
> > The same solution from 40 years ago still applies. Buy your own CI
> servers
> > and have then run your stuff instantly. Which unlike 40 years ago is
> > financially plausible now. You can even hook them up to be managed by
> cloud
> > CI like Azure Pipelines that supports custom clients. Or... Just use
> Azure
> > Pipelines which has significantly better turnaround times than Appveyor.
>
> A number of Boost libraries already run AppVeyor from their Github page
> to verify that a change is valid. I am certainly not against CI validity
> testing, but maybe Boost should explore better alternatives. When it
> takes days and days before a CI test in AppVeyor can be done while it is
> "pending", maybe there are better alternatives than AppVeyor which cover
> a very similar set of testing environments to what AppVeyor covers. I am
> gathering that AppVeyor is so slow because it is very popular and does
> not have the resources to run all its scheduled jobs within a more
> reasonable period of time.
>

Like I said (or maybe insinuated) Azure Pipelines is the better
alternative. For example that's where I run the B2 tests <
https://dev.azure.com/grafikrobot/B2/_build?definitionId=3&_a=summary>, and
a few others. Assuming you aren't contending with the 10 free parallel
slots among all of Boost, i.e. if you do your own CI setup, startup
response is usually less than a minute. Total time is of course dependent
on how much you do. Perhaps the one drawback is not as good default
coverage for MinGW and Cygwin. But you can install anything you like also
(with enough scripting voodoo).

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net