Am 19.12.19 um 09:17 schrieb Edward Diener via Boost:
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. That's not what I wanted to say. I *think* Appveyor shares its capacities over a user or a repo or an org. Hence if there are 3 open PRs, 1 commit merged you got 4xN jobs waiting to be executed. And only 1(?) will execute at a given time. So your startup latency is governed by the number of jobs the repo/user/org has queued up before. My suggestion was to reduce that number and hence the latency.
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.
Hence my suggestion for GH actions. AFAIK not all MSVC versions supported on appveyor are supported on GHA, so my suggestion was to move as many jobs from appveyor as possible