Continuous integration environment

Eric Theise erictheise at gmail.com
Tue Nov 13 15:52:46 GMT 2012


On Tue, Nov 13, 2012 at 3:19 AM, Paweł Paprota <ppawel at fastmail.fm> wrote:
> 1. Should we go for one "official" CI environment/account? cruise.osm.org
> looks like a good start if we want to have something in our own
> infrastructure.
>
> 2. Should it be possible for anyone to add their own repo/branch to such
> environment? Otherwise only the master/deploy branch of the main repo will
> be built and everyone will have to set up their own CI.

Tom's pointed out that the github project is a mirror of git.osm.org,
and that Travis is designed to work with github repos.  So there would
be a built-in delay between the time git.osm.org is updated and the
time Travis would see that change via the mirror.  I would suggest
that we use Travis as a final stamp of approval for master--I may be
easily duped, but I feel better about open source projects that have
Travis-style badges on their READMEs--and that the existing
cruise.osm.org server be resuscitated and expanded.

I do like the suggestion that developers be able to add their forks to
a central CI server that provides code coverage reports.  It should
make it easier for Tom to decide whether or not to merge a pull
request, and for developers to do code reviews.

> I personally have most experience with Hudson/Jenkins. In comparison, Cruise
> Control and Travis look rather simplistic. What would be useful is to have
> some code metrics, test breakdown, test coverage etc.

Travis has only been around since early 2011 and I don't have any idea
about where publishing code metrics fits into their roadmap.  It's
been a while since I've worked with CruiseControl.rb, but we ran a
metrics project with it, using the now-abandoned MetricFu.

http://jakescruggs.blogspot.com/2012/08/why-i-abandoned-metricfu.html
http://metric-fu.rubyforge.org/

I grew to like simplecov
https://github.com/colszowka/simplecov

Oh, I see a new message has come in from Shaun.

--Eric



More information about the rails-dev mailing list