Ironruby core - Mar 2008 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080325/b9e4daf4/attachment-0001.html

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080326/ca6904ad/attachment.html