Re: [boost] Travis CI Resources

Subject: Re: [boost] Travis CI Resources
From: James E. King, III (jking_at_[hidden])
Date: 2018-01-22 14:12:54

On Mon, Jan 22, 2018 at 9:05 AM, Peter Dimov via Boost <
boost_at_[hidden]> wrote:

> James E. King, III wrote:
>
> The desire is to ensure that pull requests submitted to repositories are
>> processed in a timely manner.  This is not happening, and there is at least
>> a 12 hour backlog on pull request builds for boostorg right now.
>>
>
> This is caused by Travis Mac resources being insufficient. There is a
> multiple day backlog for Mac jobs, and it doesn't seem to be going away -
> Travis increased their job count from 180 to 204 temporarily for the
> weekend, it didn't help, the backlog is at the moment at 1100+ and keeps
> growing. Look at https://www.traviscistatus.com/ for the stats.
>
> This should in principle not affect the Linux-only .travis.yml
> configurations, but it does, because the queued Mac jobs result in only 3
> parallel jobs being available for Linux builds, instead of the usual 5.
>
> I'd say that boostorg/math might scale down its Mac jobs a bit. :-)
>
> If this persists, we should probably not use Mac jobs at all, although
> they are kind of essential for Config and Build. Most other repos have a
> single Mac job, with a few exceptions.
>
>
>
I'm not convinced it is due to mac jobs.  I have no mac jobs in three
repositories because of the delays there; my linux-only PRs are still
experiencing a 12 hour delay running.  Right now I am supposed to submit
PRs for review, so I'm not sure I have much of a choice but to wait for the
12 hour cycle.  I have been running builds in my fork to get them working
and then submitting the PR up to the boostorg repo to get the public code
review.  Travis is at least smart enough not to block the 5 available build
runners if there are no mac resources to run anything... it'll keep running
5 concurrent.  One problem is we all have to share 5 concurrent.  That can
be fixed with money.

I just sync'd with the top level develop this morning and saw a number of
feature branches in boostorg repositories were added, so I don't think the
original guidance from last summer was heeded.

- Jim