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/