[ruby-core:17580] Re: rubyspec reports for ruby_1_8, ruby_1_8_7, and v1_8_6_p265

Stephen Bannasch wrote:
> I wanted to learn more about specs recently started using git and so I 
> wrote this:
>
>   build_ruby.rb: http://pastie.org/227446
That's pretty cool. Thanks for writing that.

Your Ruby code is certainly easier on the eyes than my shell-based 
equivalent. :)

How often is that Git repository for Ruby updated? I've been using SVN 
because it's always up to date, but would certainly prefer to use Git 
for this because I can more easily move between versions.

You may want to add a command to extract the raw results to files in a 
reports directory with filenames based on the tag and test suite, e.g., 
rubychecker creates reports like "rails_2.1.0_with_p265.log". I've been 
relying on that functionality so that I can run "gvimdiff" (or "meld", 
or "kdiff3", etc) against multiple logs and compare the results.

I'm not sure about your caching strategy. The issue is that when 
RubySpec is updated, the results will change, so there's a legitimate 
need to rebuild, although I suppose one can manually delete the YAML 
cache file.

Your code is also very closely tied to just RubySpec. It would be nice 
to see it abstracted to support arbitrary test suites. I think you need 
another object, something like TestResult which represents the results 
of a test suite, such as the raw output and the numbers of files, tests, 
failures, and such in there. The RubyBuilder object could then have a 
hash of TestResult objects, with the key being the test suite name (e.g. 
"rspec_1.1.4").

Anyway, this is very nice. Your comments were excellent and the source 
code was an enjoyable read -- I don't say that often. You may want to 
post your code onto github or something so that others can help 
collaborate with you on this.

For now, I'll keep hacking on rubychecker and experiment with its 
Ruby-based port. Hopefully one us, or Ryan Davis who was also apparently 
working on something, will come up with a good solution. :)

-igal