Continuous integration on top of rubyforge SVN, your opinion?

Hi,

What about setting up a basic continuous integration process to ensure
we
keep the core compiling (if not more) ?

I believe internally at Microsoft this process is already in place with
TFS.
It could be useful (see previous threads last week) to have a continuous
integration monitoring the rubyforge SVN as well.

It’s a bit of pain to retrieve the trunk to discover it doesn’t compile
isn’t it ?

I suggest the following tasks:

  • full clean then rake compile (for windows, for mono)
  • possibly: full clean then msbuild
  • a notification to ironruby-core when the build status changes

(a flawless “clean” ie deleting the whole folder then running svn update
could be nice).

We could implement this with a box (hosted at Microsoft ?) and
cruisecontrol.rb, for instance.

What do you think ?

cheers,

– Thibaut

[blog] http://evolvingworker.com - tools for a better day
[blog] http://blog.logeek.fr - learning content for developers

Thibaut Barrère:

What about setting up a basic continuous integration process to ensure
we keep the core compiling (if not more) ?

This is a good idea.

I believe internally at Microsoft this process is already in place
with TFS. It could be useful (see previous threads last week) to have
a continuous integration monitoring the rubyforge SVN as well.

We have a set of check-in gates here called SNAP that runs off of TFS.
When we submit our changes (or your changes) to SNAP, it runs through a
set of check-in tests. SNAP parallelizes our tests across a farm of ~20
machines. It takes at least 30 minutes for SNAP to complete a check-in
for Ruby. Once SNAP blesses the check-in it submits it to TFS and
commits the change.

As you might imagine, we don’t have Linux in our test matrix, and it
would be a very large work item to add it to SNAP. In a way, we’re
really relying on you (this means you, Seo :)) to keep filing bug
reports on whether things are building and running on Mono.

It’s a bit of pain to retrieve the trunk to discover it doesn’t
compile isn’t it ?

This is entirely my fault. As I was rewriting the Rakefile to deal with
multiple targets and fixing the source and project transformations,
things got in an inconsistent state. Things should be much better from
this point onward. We also have a gap in our SNAP tests - the specs
weren’t reporting some failures for some reason (we’re investigating
why) and that caused the breakage in the rake spec test suite which was
fixed yesterday.

I suggest the following tasks:

  • full clean then rake compile (for windows, for mono)
  • possibly: full clean then msbuild
  • a notification to ironruby-core when the build status changes

(a flawless “clean” ie deleting the whole folder then running svn
update could be nice).

We could implement this with a box (hosted at Microsoft ?) and
cruisecontrol.rb, for instance.

While this is a good idea for Mono, I’m not sure what this buys us that
SNAP doesn’t already for Windows. In an ideal world we would have Mono
in SNAP, but that isn’t happening anytime soon …

It seems like Seo’s doing a good job of being a human CI server for the
Mono builds - do we need more for the time being?

Thanks,
-John

Hi John,

Thanks for the SNAP insight first! I believe it’s enough for the time
being.

Out of curiosity, is SNAP calling the rake task ?

If we meet inconsistencies in the future (ie things work in TFS but not
from
a SVN/rubyforge user point of view), it may be worth setting up
something
though.

cheers

– Thibaut

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs