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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-12-04 12:52:18

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. On 
Jenkins I have a clang static analysis preflight check off which all 
other jobs hang as a dependency, so if the static analysis fails I 
know I've done something really stupid e.g. forgot to commit a file.

> I may be stretching the purpose of Travis, I realise :)

If a commit could be rejected because Travis says no, I think that 
would a hugely useful feature. That isn't available to us, so sure a 
pull request automated scanner and rejector looks the next best 
thing. It just requires, I suppose, someone to do the work. I guess I 
have much more experience here than I should thanks to AFIO.

Sometime soon after this modularisation we're surely going to have to 
add dependencies support to Boost modules so say Boost.AFIO can say 
it really needs Boost.Filesystem for example. Right now we have to 
rely on build failures to spot missing dependencies. It isn't ideal, 
especially for Travis as you have to hardcode the git clone of the 
right submodules as pulling the kitchen sink takes too long. That 
sounds brittle, and not especially maintainable.

> > While messy and generating a lot of unhelpful noise, I haven't found
> > any way better than bot-posted comments so far. Unfortunate, but it
> > does work.
> 
> Makes sense to me.

The problem with bot commenting is you, and everyone else in the 
project, gets an email for every comment. This because very wearing 
after a while, puts you off making pull requests :(

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/