At 7:53 AM +0900 7/4/08, Igal Koshevoy wrote:
>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?

Right now every hour at 54 minutes past the hour.

>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.

Thanks for all the suggestions. There is much that can be improved ;-) The strategy was to write something that worked as FAST as as I could!

I wanted to get sopmething out on the list because I think it's important to get better integration between the rubyspecs tests and Ruby releases.

>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. :)

I don't know how much more I can do now (other priorities are looming) of course it is very attractive to get this working right and your ideas are good.

I will put it somewhere like github where others can more easily contribute.