Boost logo

Boost :

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-12-19 19:04:32


On Thu, 19 Dec 2019 at 20:00, Edward Diener via Boost
<boost_at_[hidden]> wrote:
> On 12/19/2019 12:29 PM, Mateusz Loskot via Boost wrote:
> > On Thu, 19 Dec 2019 at 18:17, Edward Diener via Boost<boost_at_[hidden]> wrote:
> >> On 12/19/2019 3:27 AM, Alexander Grund via Boost wrote:
> >>>
> >>> 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
> >>
> >> I guess I do not understand under whose account an Appveyor job gets run
> >> for a particular Boost Github repository. I can see under Appveyor that
> >> I have projects based on Boost Github repositories, but does this mean
> >> that if someone triggers off an Appveyor job by updating a repository it
> >> is run under my personal Appveyor account, their personal Appveyor
> >> account, or some Appveyor account registered to the Boost organization
> >> in general ?
> >
> > AFAIK,all existing AppVeyor-s for all libraries under
> > https://github.com/boostorg/*
> > are attached to personal/maintainer's account, e.g.
> > https://ci.appveyor.com/project/stefanseefeld/gil/ for
> > https://github.com/boostorg/gil
>
> How can I see on a Github Boost library's web page which personal
> maintainer's AppVeyor account is being used ?

I don't know any way to request AppVeyor for "Who builds github.com/x/y?".

If a library maintainer sets up the AppVeyor, I'd expect her/him to add
badge to the library's README.md, as many Boost libraries do.

Best regards,

-- 
Mateusz Loskot, http://mateusz.loskot.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk