Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at