About the RubyOnRails build xxxx failed

This group is inundated with the automated cruise control posts of

RubyOnRails build xxxx failed

This comes across as a spam to me. Is this helping any one at all?

- Yes it's useful
- No, it isn't spam
- Feel free to put a filter in your mail user agent to get rid of these

    -- Jean-François.

Except, someone needs to kick CC.rb. It is showing completely irrelevant errors.

When does an error reported from continuous integration classify as irrelevant?


Or just have a look at any recent emails from cc.rb

When does an error reported from continuous integration classify as

There's obviously something wrong with it as it reports failures that
I don't see on either of my development systems. However, we
definitely have one error which david deliberately added a few weeks
ago (the NoMethodError in caching).

As annoying as those emails are, I'd hope that they act as an
incentive to investigate the error and provide a fix :slight_smile:

I agree completely, Koz :wink: The errors mean Rails is broken, on the CI
system that Alexey is providing as a service (Thank You!). The only
reason that these errors could be irrelevant is if Alexey's CI
environment is invalid. If you think that is the case, then either
set up your own passing CI build and send it to the list, or
investigate why Alexey's is broken.

AND, since Alexey's was green up until someone checked in a failing
build, I would blame the failing checkin before the Ci system, at
least in absence of any other evidence (and I have not seen any on the
list - if there was it needed a better subject).

Every time I see a failing Rails build message, I want to fix it.
Unfortunately, not enough to prioritize fixing the Rails build higher
than my own personal tasks, but I definitely don't consider it
irrelevant. I consider it more of a statement on the discipline of
whoever isn't fixing the build (including myself, as a Rails user),
and the Rails development community as a whole. Especially on the
people that bitch about it rather than fixing it (did it really take
longer to send an email complaining about it than to set up a filter?
If so, you should be using gmail).

Tests are important. They should always be passing in trunk and the
stable release branch. If you can't make it pass, delete it, or
disable it with a loud reminder.

-- Chad

The no method error in caching has a patch at http://dev.rubyonrails.org/ticket/10733

I'm not getting the errors the CI build report either, but that's
fairly recent.

Michael Koziarski wrote:

Yup, please help verify (or just apply) it. Thanks!

The patch is here: http://dev.rubyonrails.org/ticket/10733


Chu Yeow

Hi, guys,

When this last series of failing builds started, and for some days
after, it was a genuine test failure. Thanks for the heads up that
it's not anymore - I'll try to fix the server today.

Whenever you see the CI build failing, and think it's the CI server
problem, please let me know.


1. http://dev.rubyonrails.org/changeset/8735 caused some crazy number
of AR tests for Postgres and SQLite failing because of missing
posts.comments_count column.

2. This caused the build log to be nearly 3Mb long, and the dashboard
was choking up on it (because it runs a couple of fancy regexes
against the build log when displaying a build page). It's odd that
nobody had this problem before, but this is something I need to fix in

3. Failing AR tests were fixed by http://dev.rubyonrails.org/changeset/8745

4. There are still some test failures (all genuine, all reproducible
on my laptop), but at least one can open the build page and see what
they are.