Re: [appveyor] Really slow turnover

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-12-19 08:17:15

On 12/19/2019 2:40 AM, Alexander Grund via Boost wrote:
> I had a similar problem (additionally) with travis: It is not as bad 
> there but with about 32 jobs running with different compilers per PR and 
> commit (on dev/master) the turnaround got quite low.
> 
> What I did first was to cut down on jobs on PRs: I only test latest + 
> oldest clang and g++ now. I still run the full suite on dev/master 
> commits (and hence after merge) to detect regressions in compilers 
> causing failures in my library.
> 
> What can also help: Spread out your jobs: Currently there are at least 3 
> CI services which offer free windows testing:
> 
> - Appveyor
> - Travis
> - Github actions
> - (Azure pipelines? Haven't tried yet)
> 
> Especially GH actions is very fast (currently), so this offers a way to 
> reduce the pressure on Appveyor jobs. Run what you can on GH actions and 
> the rest on appveyor.
> 
> Except for the lack of YAML references I like their (GHA) Job 
> descriptions much better. They allow matrices per job, multiple jobs per 
> yaml and multiple yamls as well as using "building blocks" from your or 
> other repos. Give it a try! :)

First it is not my Github Boost repository but rather other Boost 
repositories if/when I submit a PR. Second I do not think it is the 
amount of jobs in a test, as the test will say "pending" for a number of 
days without anything being run at all. It's like the CI Appveyor 
automatically triggered by the PR change in Github is just heavily 
backlogged and will not run for days while it is pending because there 
are other CI Appveyor tests from other Internet users it must run first 
on its queue. So some Github CI Appveyor test can be queued for days 
until it actually runs. I really, really doubt that the CI Appveyor test 
itself is actually running and taking days to complete.

My point is that if CI Appveyor tests takes days before it is even 
started, when a PR is made against a Boost repository, maybe Boost 
should be a bit proactive and suggest to library maintainers that some 
other CI testing service, like the Azure mentioned by Rene, would be 
much faster and therefore should be used in place of Appveyor. Maybe I 
am being unduly impatient but programmers have come to expect that when 
tests of any kind can be run it shouldn't take days in modern computing 
to just start the actually testing procedure.