Re: [boost] Pull request sanitise run on Travis CI (Re: [git] Near future.. How do we deal with git-native libraries?)

Subject: Re: [boost] Pull request sanitise run on Travis CI (Re: [git] Near future.. How do we deal with git-native libraries?)
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-12-07 15:11:05

Mateusz Loskot <mateusz_at_[hidden]> writes:

> On 4 December 2013 17:52, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>> On 2 Dec 2013 at 17:59, Mateusz Loskot wrote:
>>
>>> > Given the work involved, and Travis's fairly restricted per job
>>> > timeout, I think this will be a per-maintainer effort. It might be
>>> > possible for a single "Does it build on Linux with default GCC?"
>>> > sanity run yes, but for anything beyond that I fear it will be a
>>> > per-project initiative. It took me many weeks to get AFIO's automated
>>> > build infrastructure working right. I can't see anyone volunteering
>>> > that time except for their own libraries.
>>>
>>> I should have explained my idea clearer, I didn't mean to use Travis CI for
>>> actual builds (compilation+ linking), because there are certain limitations,
>>> as you pointed.
>>>
>>> I meant to use Travis CI for some support lightweight tasks such as sanitising
>>> PRs, running Inspect, and perhaps hook-like things.
>>> Simply, to use Travis as Unix shell, not for running actual builds or
>>> regression tests.
>>
>> Oh sure. Travis is very flexible. For example I have a job on there
>> whose sole purpose is the run the unit tests with gcov and upload the
>> coverage to Coveralls.io, because coveralls.io has special support
>> for Travis. My only irritation with Travis is there is no such thing
>> as job dependencies, so all jobs always run with each commit.
>
>
> You're right, for such a complex project like Boost, that is quite a limitation.

Travis testing of boost projects should generally be done against the
latest release of all the other projects, so it wouldn't really be that
bad.