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.