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

Subject: Re: [geometry] Setting up Travis CI for Boost.Geometry
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2014-11-10 08:44:21

On 10 November 2014 12:54, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
> 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.

The "we should configure" requires just
1) add .travis.yml file to branches we aim to build on Travis
2) maintain .travis.yml synchronised across all the configured branches

See http://docs.travis-ci.com/user/build-configuration/#Specify-branches-to-build

"configuration in one branch will not affect the build of another,
separate branch"

Also, even if we have .travis.yml in all branches, we can explicitly
include/exclude
those we want to build. For instance, we can exclude any branches other than
develop and master.

> We rarely push
> something to master branch so it doesn't represent well the state of current
> development.

Yes, I'm aware, but still it's good to have feedback on status of master,
it does not cost any extra maintenance effort really.

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

I'd strongly advise to NOT to create any extra branches.
Typically, we have master and develop and we simply configure them for Travis.
Every time commits are pushed to develop, build is fired up.
Every time develop is merged back to master, what sporadically, build
against master is fired up.

> Would it be possible to have separate icons in the README for different
> parts of the library?

AFAIK, Travis generates single non-customisable icon for all builds. So, no.

I've learned one more potential issue with splitting up tests into groups:
each group triggers separate build.
Let me explain:
- if there are no ENV groups in build matrix, then build with single
job is created with number #X
- if there are ENV groups in build matrix, then we have build with
multiple jobs #X.Y (see dot)
Now, in the latter case of multi-job builds, I'm not sure how to
accumulate statistics for coveralls.io.
Likely, for each job, coveralls would display separate statistics,
like here for example (see JOBS section, with 15.1, 15.2)
https://coveralls.io/builds/560853
I will have to investigate it, but let's focus on Travis CI first.

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

In most, if not all, projects I maintain with .travis.yml, all copies
of the config file
is exactly the same in every branch. There is hardly every need to customise
.travis.yml per branch, it's generic config.

> Btw, would it be possible to configure Coveralls to not take into account
> some of the directories while calculating coverage?

AFAIK, yes, as coveralls data is generated by shell script using gcov, see
https://github.com/eddyxu/cpp-coveralls

> Would it be possible to again separate the main part, spatial index and
> extensions this way?

Yes, we can configure build matrix as we like.
For example, for SOCI I split by database backend
https://travis-ci.org/SOCI/soci/builds/28486109

It's all based on setting ENV variable and then Bash-like if-else branching
on what to build, how to build, with what options, etc.
It's highly flexible.

If I receive green light, I'll add .travis.yml to boostorg/develop and
tweak it there,
so we can see how it behaves on real-life repo activity.
Once we're happy, we simply add .travis.yml to master and we are done :)

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