Geometry Boost List: Re: [geometry] Setting up Travis CI for Boost.Geometry

Subject: Re: [geometry] Setting up Travis CI for Boost.Geometry
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-11-10 06:54:08

Hi Mateusz,

Mateusz Loskot wrote:
> On 8 November 2014 19:40, Mateusz Łoskot <mateusz_at_[hidden]> wrote:
>> What is built by Travis CI?
>> 1. Boost.Geometry branch which contains .travis.yml, typically, master
>> and develop,
>> and branches branched off of those.
>> 2. Boost.Geometry clone is deployed into Boost 1.57.0 release source code tree.
>> That is because cloning Boost master-repo would takes too long.
> It turns out there is a way to base the build on he Boost master-repo
> and make the clones quick.
> The Boost.Variant may serve as an example here:
> https://github.com/apolukhin/variant/tree/travisci
>
> Actually, Antony posted Travis CI suggestion to Boost ml in Sept:
> http://lists.boost.org/Archives/boost/2014/09/216960.php
>
>> What next?
>> I'd like to submit Travis CI configuration to master and develop
>> branch in the upstream repo.
>> Apart from commit, the only action that is required is activation of
>> GitHub Webhook
>> (step 2 in How it works? above) which requies boostorg/geometry admin access.
>> Is this step feasible for us or we need to contact any Boost project wizards?
> Hmm, it looks that github.com/boostorg repositories are already Travis
> CI enabled,
> means they have the hook activated, as Antony wrote:
> "the parent repository was already Travis enabled"
> http://lists.boost.org/Archives/boost/2014/09/217087.php
> So, that issue might have already been solved.
>
>
> Check also the table in the README with test coverage status.
> It is provided by coveralls.io service:
> https://coveralls.io/r/apolukhin/variant?branch=travisci
> It would be nice to add it too.

All of this looks great!

So, AFAIU if we decided to use Travis and/or Coveralls we should 
configure master and develop separately and run tests for them both. We 
rarely push something to master branch so it doesn't represent well the 
state of current development. Or should we have 2 additional branches 
synchronized with develop and master for the purpose of EXTERNAL 
testing? The drawback is that we'd be forced to synchronize them 
manually so I guess configuring master and develop directly is a better 
solution.

Would it be possible to have separate icons in the README for different 
parts of the library? E.g. for:
- test
- index/test
- extensions/test
- example
- index/example
- extensions/example
- doc/src/examples
- doc/index/src/examples

Then we could create a nice matrix in the README. This means that README 
and those config files (travis.yml and probably some from coveralls?) 
should be different in develop and master branch so this would make 
releasing new version (merging) slightly harder. I'm guessing that not 
much harder than handling extensions and that Barend has it covered, 
though it'd be another thing that one must do/remember.

Btw, would it be possible to configure Coveralls to not take into 
account some of the directories while calculating coverage?
Would it be possible to again separate the main part, spatial index and 
extensions this way?

Regards,
Adam