|
Boost : |
From: Edward Diener (eldiener_at_[hidden])
Date: 2019-12-19 19:00:13
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 have a number of
AppVeyor projects for Boost Github libraries which I no longer follow or
help maintain as a previous member of CMT, and I would like to have
someone else be associated with those Appveyor projects.
>
> There is no official organization account for Boost on AppVeyor.
>
> It is possible to create one though
> https://www.appveyor.com/docs/team-setup/#setting-up-appveyor-account-for-github-organization
>
> Best regards,
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk