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: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-12-02 12:59:37

On 2 December 2013 17:48, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 2 Dec 2013 at 16:20, Mateusz Loskot wrote:
>
>> > Later on I think it very likely a script might scan all pull requests
>> > to ensure their commits were made using the canonical Boost
>> > .gitattributes, and if they weren't to refuse the pull request.
>>
>> GitHub pull requests (PR) are nicely handled by Travis CI service
>> (https://travis-ci.org/).
>
> While a good idea, we can do a lot better again.
>
> I have a reasonable Jenkins + Travis + Coveralls implementation also
> working for every pull request to master branch. It took a while to
> get the kinks out, but you can see the pull request commentary at
> https://github.com/BoostGSoC/boost.afio/pull/48 where the bots
> decided if my "Boost v1.55 RC merge" pull request was valid.

Interesting, I'll take a look at that PR.

>> Perhaps, it would make sense to set up Travis for Boost repositories as well.
>> Then, for every PR submitted to one of Boost repos, a Travis build is performed
>> and PR sanitisation script could be part of that build.
>
> 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.

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

>> A nice feature of GitHub+Travis integration is that GitHub PR ticked
>> will automatically display status of corresponding Travis build,
>> warning about broken that particular PR is broken, so merge with caution, etc.
>
> While nice, it's too subtle for me. It also doesn't work if multiple
> bots are posting status to the same pull request, so if say the
> Windows unit test run succeeds but Linux fails, you have a 50/50
> chance of seeing that the pull request has failed. This is a stupid
> limitation of github, where apparently the only possible CI target is
> one.

I see, I didn't realise that.

> 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.

Best regards,
-- 
Mateusz  Łoskot, http://mateusz.loskot.net