Setting up Travis CI for Boost.Geometry

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
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 mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> 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.

Best regards,
--
Mateusz  Łoskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
Hi Mateusz,

Mateusz Loskot wrote:

> On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> 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
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
On 10 November 2014 12:54, Adam Wulkiewicz <[hidden email]> wrote:

> Mateusz Loskot wrote:
>> On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> 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
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
Mateusz Loskot wrote:
> On 10 November 2014 12:54, Adam Wulkiewicz <[hidden email]> wrote:
>> 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'm asking because e.g. some of the extensions are broken so if they
were included in the build the icon would probably always be red for all
of the tests.
Furthermore it'd be convenient to have those parts separated.

AFIO has many icons in their README but indeed there is only one from
Travis.
https://github.com/BoostGSoC13/boost.afio

What if we made some dummy branches, each one testing one part of the
library?
Would it be possible to setup some hooks on GitHub to automatically
update those branches when new commits were pushed to e.g. develop?

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
On 10 November 2014 16:31, Adam Wulkiewicz <[hidden email]> wrote:

> Mateusz Loskot wrote:
>>
>> On 10 November 2014 12:54, Adam Wulkiewicz <[hidden email]>
>> wrote:
>>>
>>> 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'm asking because e.g. some of the extensions are broken so if they were
> included in the build the icon would probably always be red for all of the
> tests. Furthermore it'd be convenient to have those parts separated.

I understand, but that use case is too complicated from the point of
continuous integration which is supposed to produce boolean answer:
green/red :-)

If some parts of software fail to build/test and that is acceptable state,
then those parts should be excluded from CI builds.

> AFIO has many icons in their README but indeed there is only one from
> Travis.
> https://github.com/BoostGSoC13/boost.afio

Yes, Travis status image is generated per branch build:
https://api.travis-ci.org/mloskot/geometry.svg?branch=master
https://api.travis-ci.org/mloskot/geometry.svg?branch=develop
,,,
No customisations.

> What if we made some dummy branches, each one testing one part of the
> library?

How would that differ from telling b2 what to build?

b2 target1 target2 target3

...but not target4.

> Would it be possible to setup some hooks on GitHub to automatically update
> those branches when new commits were pushed to e.g. develop?

Perhaps it's possible, but I lack of GH fu here, so can't help with this.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
Mateusz Loskot wrote:

> On 10 November 2014 16:31, Adam Wulkiewicz <[hidden email]> wrote:
>> AFIO has many icons in their README but indeed there is only one from
>> Travis.
>> https://github.com/BoostGSoC13/boost.afio
> Yes, Travis status image is generated per branch build:
> https://api.travis-ci.org/mloskot/geometry.svg?branch=master
> https://api.travis-ci.org/mloskot/geometry.svg?branch=develop
> ,,,
> No customisations.
>
>> What if we made some dummy branches, each one testing one part of the
>> library?
> How would that differ from telling b2 what to build?
>
> b2 target1 target2 target3
>
> ...but not target4.

Since AFAIU Travis generates a result image per branch, the only way to
generate multiple images (for various parts of the lib) is to run the
tests for various (dummy) branches each testing a part. Those resulting
images may be then inserted into one README. Or am I missing something?

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
Adam Wulkiewicz wrote:

> Mateusz Loskot wrote:
>> On 10 November 2014 16:31, Adam Wulkiewicz
>> <[hidden email]> wrote:
>>> AFIO has many icons in their README but indeed there is only one from
>>> Travis.
>>> https://github.com/BoostGSoC13/boost.afio
>> Yes, Travis status image is generated per branch build:
>> https://api.travis-ci.org/mloskot/geometry.svg?branch=master
>> https://api.travis-ci.org/mloskot/geometry.svg?branch=develop
>> ,,,
>> No customisations.
>>
>>> What if we made some dummy branches, each one testing one part of the
>>> library?
>> How would that differ from telling b2 what to build?
>>
>> b2 target1 target2 target3
>>
>> ...but not target4.
>
> Since AFAIU Travis generates a result image per branch, the only way
> to generate multiple images (for various parts of the lib) is to run
> the tests for various (dummy) branches each testing a part. Those
> resulting images may be then inserted into one README. Or am I missing
> something?
>

Or maybe better, to not create dummy branches in the original repo we
could have a fork designated for testing with all of the additional
branches and configuration files, etc.
We should just figure out how to automatically update it after
develop/master was changed, or at least how to update it periodically.

> Regards,
> Adam


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
In reply to this post by Adam Wulkiewicz
On 10 November 2014 19:28, Adam Wulkiewicz <[hidden email]> wrote:

> Mateusz Loskot wrote:
>> On 10 November 2014 16:31, Adam Wulkiewicz <[hidden email]> wrote:
>>>
>>> AFIO has many icons in their README but indeed there is only one from
>>> Travis.
>>> https://github.com/BoostGSoC13/boost.afio
>>
>> Yes, Travis status image is generated per branch build:
>> https://api.travis-ci.org/mloskot/geometry.svg?branch=master
>> https://api.travis-ci.org/mloskot/geometry.svg?branch=develop
>> ,,,
>> No customisations.
>>
>>> What if we made some dummy branches, each one testing one part of the
>>> library?
>>
>> How would that differ from telling b2 what to build?
>>
>> b2 target1 target2 target3
>>
>> ...but not target4.
>
>
> Since AFAIU Travis generates a result image per branch, the only way to
> generate multiple images (for various parts of the lib) is to run the tests
> for various (dummy) branches each testing a part. Those resulting images may
> be then inserted into one README. Or am I missing something?

Yes, that's correct.

Best regards,,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
In reply to this post by Adam Wulkiewicz
On 10 November 2014 19:36, Adam Wulkiewicz <[hidden email]> wrote:

> Adam Wulkiewicz wrote:
>> Mateusz Loskot wrote:
>>> On 10 November 2014 16:31, Adam Wulkiewicz <[hidden email]> wrote:
>>>>
>>>> AFIO has many icons in their README but indeed there is only one from
>>>> Travis.
>>>> https://github.com/BoostGSoC13/boost.afio
>>>
>>> Yes, Travis status image is generated per branch build:
>>> https://api.travis-ci.org/mloskot/geometry.svg?branch=master
>>> https://api.travis-ci.org/mloskot/geometry.svg?branch=develop
>>> ,,,
>>> No customisations.
>>>
>>>> What if we made some dummy branches, each one testing one part of the
>>>> library?
>>>
>>> How would that differ from telling b2 what to build?
>>>
>>> b2 target1 target2 target3
>>>
>>> ...but not target4.
>>
>>
>> Since AFAIU Travis generates a result image per branch, the only way to
>> generate multiple images (for various parts of the lib) is to run the tests
>> for various (dummy) branches each testing a part. Those resulting images may
>> be then inserted into one README. Or am I missing something?
>>
>
> Or maybe better, to not create dummy branches in the original repo we could
> have a fork designated for testing with all of the additional branches and
> configuration files, etc.

IMHO, adding any extra planes of build status sounds like an overkill.
We have build status per branch (after last commit).
We decide that we build only those parts that are actively maintained.
We get green, we're good.
We get red, we must fix to get green.

In the Boost.Geometry upstream, this is all we should care about, really:

branch   | status
-----------------------
develop |  GREEN
master  |  GREEN

IMHO, users should be able to get stable (master) or cutting edge (develop)
package of what is actively maintained, without any unsupported legacies.

Regarding extensions that are broken, they either should be fixed
if actively maintained and supported
or moved to separate repository
if not maintained, orphaned and unsupported.

That said, I'd rather consider, either dedicated
repository github.com/boostorg/geometry-extensions
or
Boost.Geometry team organization github.com/boostorg-geometry
where such repositories can be maintained:
github.com/boostorg-geometry/extensions-orphaned
github.com/boostorg-geometry/extensions-proposed
...

my 5 cents

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
Mateusz Loskot wrote:

>
> We have build status per branch (after last commit).
> We decide that we build only those parts that are actively maintained.
> We get green, we're good.
> We get red, we must fix to get green.
>
> In the Boost.Geometry upstream, this is all we should care about, really:
>
> branch   | status
> -----------------------
> develop |  GREEN
> master  |  GREEN
>
> IMHO, users should be able to get stable (master) or cutting edge (develop)
> package of what is actively maintained, without any unsupported legacies.

Yes, you're right.
Furthermore this should encourage people to fix all bugs, not only e.g.
the ones in the main part.
And it'd be indeed clear for the users if the current version is ok or
broken.

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
In reply to this post by Mateusz Loskot
Mateusz Loskot wrote:
> Regarding extensions that are broken, they either should be fixed
> if actively maintained and supported
> or moved to separate repository
> if not maintained, orphaned and unsupported.

I agree. Actually I think that we should ASAP release them (or some of
them) and have no more extensions.

> That said, I'd rather consider, either dedicated
> repository github.com/boostorg/geometry-extensions
> or
> Boost.Geometry team organization github.com/boostorg-geometry
> where such repositories can be maintained:
> github.com/boostorg-geometry/extensions-orphaned
> github.com/boostorg-geometry/extensions-proposed
>

Then if there were no extensions new features would exist in forks of
people working on them. The code would be merged into the main
repository only if it was finished. It'd then be maintained properly.

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
In reply to this post by Adam Wulkiewicz
On 10 November 2014 21:35, Adam Wulkiewicz <[hidden email]> wrote:

> Mateusz Loskot wrote:
>>
>> We have build status per branch (after last commit).
>> We decide that we build only those parts that are actively maintained.
>> We get green, we're good.
>> We get red, we must fix to get green.
>>
>> In the Boost.Geometry upstream, this is all we should care about, really:
>>
>> branch   | status
>> -----------------------
>> develop |  GREEN
>> master  |  GREEN
>>
>> IMHO, users should be able to get stable (master) or cutting edge
>> (develop)
>> package of what is actively maintained, without any unsupported legacies.
>
>
> Yes, you're right.
> Furthermore this should encourage people to fix all bugs, not only e.g. the
> ones in the main part.

Yes, indeed.
Actually, I often rely on such status to motivate myself and look into a project
for broken parts that I may be able to fix.
I hope, that such status (with detailed log) would also encourage potential
bug shooters.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Mateusz Loskot
Administrator
In reply to this post by Mateusz Loskot
On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> wrote:

> [...]
>
> 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?

Folks,

So, what we do with this proposal?
Is everyone in favour of incorporating it into master and develop or
drop & forget?

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Adam Wulkiewicz
Mateusz Loskot wrote:

> On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> wrote:
>> [...]
>>
>> 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?
> Folks,
>
> So, what we do with this proposal?
> Is everyone in favour of incorporating it into master and develop or
> drop & forget?

I'm of course in favor of enabling the testing.

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Barend
Hi,

Adam Wulkiewicz wrote On 12-11-2014 1:07:

> Mateusz Loskot wrote:
>> On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> wrote:
>>> [...]
>>>
>>> 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?
>> Folks,
>>
>> So, what we do with this proposal?
>> Is everyone in favour of incorporating it into master and develop or
>> drop & forget?
>
> I'm of course in favor of enabling the testing.


I'm in favour too, thanks for setting this up Mateusz!

Regards, Barend



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting up Travis CI for Boost.Geometry

Menelaos Karavelas
Hi Mateusz.

On 12/11/2014 11:36 πμ, Barend Gehrels wrote:

> Hi,
>
> Adam Wulkiewicz wrote On 12-11-2014 1:07:
>> Mateusz Loskot wrote:
>>> On 8 November 2014 19:40, Mateusz Łoskot <[hidden email]> wrote:
>>>> [...]
>>>>
>>>> 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?
>>> Folks,
>>>
>>> So, what we do with this proposal?
>>> Is everyone in favour of incorporating it into master and develop or
>>> drop & forget?
>>
>> I'm of course in favor of enabling the testing.
>
>
> I'm in favour too, thanks for setting this up Mateusz!
>
> Regards, Barend
>
>

+1 from me.

- m.

>
> _______________________________________________
> Geometry mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/geometry

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Loading...