|
Geometry : |
Subject: [geometry] Setting up Travis CI for Boost.Geometry
From: Mateusz Åoskot (mateusz_at_[hidden])
Date: 2014-11-08 13:40:18
Hi,
I have been playing with Travis CI (https://travis-ci.com) for the project
to perform continuous integration builds upon commit.
I have managed to get a reasonably working configuration.
How it works?
1. Created .travis.yml config in master of
https://github.com/mloskot/geometry repo
2. Activated GitHub Webhook on mloskot/geometry repo
3. Upon every commit, Travis CI fires up a build running commands
specified in .travis.yml
4. Build status and history (with complete shell output) can be accessed
https://travis-ci.org/mloskot/geometry/
5. Notifications can be configured, e.g. to e-mail about build failure/success
Here is build #14 where you can see the whole build matrix
https://travis-ci.org/mloskot/geometry/builds/40390216
(Please, ignore any builds earlier than #14 asirrelevant and were used to test
.travis.yml configuatrion.)
You can see green/red status and basic info about compiler,
environment and timing.
If you click on any of the 14.[1-8] links, you can see complete build
output as you'd see it in shell prompt.
You can also see the build matrix shows clickable reference to the git commit
on GitHub and there is status icon at the bottom of the README.md, see
https://github.com/mloskot/geometry/blob/master/README.md
How to read the build matrix?
You can see there are
1) Two groups per compiler: 14.[1-4] for gcc and 14.[5-8] for clang
2) Four ENV with TEST_GROUPS variable specifying which tests to build
Generally, ENV feature is optional on Travis CI, but compilation of our tests
takes very long time. On Travis CI, there is time limit of 50 minutes.
So, I grouped the tests in order to make each build complete its job
within 50 minutes.
This is a typical strategy to speed up builds:
http://docs.travis-ci.com/user/speeding-up-the-build/
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.
What's the purpose?
Simple, it's a basic continuous integration of the project that gives feedback
on project status upon every commit. It makes it possible to identify offending
commits and find regressions instantly.
Another useful feature is integration of GitHub pull requests. If someone
submits pull request, it is automatically built on Travis CI giving feedback
on status of pull request, if it breaks anything, etc.
Here are sample builds for PRs submitted to SOCI project
https://travis-ci.org/SOCI/soci/pull_requests
Note, Travis CI has similar but different purpose than Boost regression
and they should be seen as complementary facilities.
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?
I'm looking forward to hearing what you think, shall we enable
Boost.Geometry with Travis CI?
Best regards,
-- Mateusz Åoskot, http://mateusz.loskot.net
Geometry list run by mateusz at loskot.net