On 4 December 2013 17:52, Niall Douglas
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.
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.
I also have experience with Travis, configured it for a bunch of C++ projects, each with numerous and sometimes complex dependencies. So, if we see Travis useful for Boost at some point, I may help as well.
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.
I think revisions matching is the common way to juggle submodules. That's what Qt does, I think:
From "Using latest branches in the submodules" at http://qt-project.org/wiki/Building_Qt_5_from_Git
"By default the checkout will not contain the latest stable/dev branches of each individual submodule repository, but a combination of versions that are known to work together."
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 :(
BTW, I at some point for SOCI project, was playing with sending GitHub notifications to a dedicated mailing list, subject lines prepared to indicate matter (i.e. comment or new issue, what label of issue) Such system allows use of e-mail inbox filtering and avoid unnecessary noise. I stole this idea from libusbx folks: http://pete.akeo.ie/2012/07/using-rss2email-and-github-feeds-to.html Best regards, -- Mateusz Ĺoskot, http://mateusz.loskot.net