On 2 December 2013 17:48, Niall Douglas
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