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

Mateusz Loskot writes:

On 4 December 2013 17:52, Niall Douglas 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.