Cruisecontrolrb users - Mar 2010 - cruise fails when projects have AR observer and there is no development database.

Hi.

I just introduced an AR observer into my project. That made my CI
builds fail.

The error in the build log was this:
------------------------------------------------------------
home/cruise/.cruise/projects/pegasus/work cruise$ ruby1.8 -e "require
''rubygems'' rescue nil; require ''rake''; load
''/home/cruise/cruisecontrol-1.4.0/tasks/cc_build.rake''; ARGV
<< ''--nosearch'' << ''cc:build'';
Rake.application.run; ARGV.clear"
rake aborted!
FATAL:  password authentication failed for user "pegasus_dev"
------------------------------------------------------------

pegasus_dev is the name of the database in my development
environment. On my CI machine (where cc.rb runs), there is no
DB nor DB user for development environment.

I confirmed that when I outcommented my configuration line enabling my
observer like this in config/environment.rb
------------------------------------------------------------
  # config.active_record.observers = :order_state_observer
------------------------------------------------------------
then things started to work again.

But why the sudden was CC.rb sudenly starting to use my development
environment?

So I got curious: I went to my CI machine
~/.cruise/projects/pegasus/work and ran (adding the --trace argument)
ruby1.8 --debug -e "require ''rubygems'' rescue nil;
require ''rake''; load
''/home/cruise/cruisecontrol-1.4.0/tasks/cc_build.rake''; ARGV
<< ''--nosearch'' << ''--trace''
<< ''cc:build''; Rake.application.run; ARGV.clear"
2> ~/trace.err 1> ~/trace.out

That showed that when configuring observer, the
ENV[''RAILS_ENV''] ''test'' statement in
cc_build.rake:38 is not propagated properly to the
project rake task db:test:purge, it has to be set on a higher level.

So I added the argument ''RAILS_ENV=test'' to the build command,
and things work.

Here is a patch the the build model.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccrb.patch
Type: text/x-patch
Size: 1021 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20100308/f1ade6aa/attachment-0001.bin>
-------------- next part --------------

I have created ticket #278

Jarl


-- 
Jarl Friis
Gavia Technologies ApS
Om?gade 8, 2.sal
2100 K?benhavn ?.
Denmark
Phone:  +45 26 13 20 90
E-mail: jarl at gavia.dk
LinkedIn: www.linkedin.com/in/jarlfriis

On Mon, Mar 8, 2010 at 9:04 AM, Jarl Friis <jarl at gavia.dk>
wrote:
> That showed that when configuring observer, the
ENV[''RAILS_ENV''] > ''test'' statement in
cc_build.rake:38 is not propagated properly to the
> project rake task db:test:purge, it has to be set on a higher level.
Thanks for the report Jarl, but I''d like to get more details before
sprinkling more RAILS_ENV around.

Why isn''t RAILS_ENV propagated to db:test:purge?  It is just being
called via Rake::Task[task_name].invoke, which should pass it along.
Plus, db:migrate obviously has no problems...

Are you sure this isn''t a bug in your app or the specific version of
Rails you are using?

-- Chad

Chad Woolley <thewoolleyman at gmail.com> writes:
> On Mon, Mar 8, 2010 at 9:04 AM, Jarl Friis <jarl at gavia.dk> wrote:
>> That showed that when configuring observer, the
ENV[''RAILS_ENV''] >> ''test'' statement
in cc_build.rake:38 is not propagated properly to the
>> project rake task db:test:purge, it has to be set on a higher level.
>
> Thanks for the report Jarl, but I''d like to get more details
before
> sprinkling more RAILS_ENV around.
>
> Why isn''t RAILS_ENV propagated to db:test:purge? 
It never reaches that far, it never succeds to boot rails!

Even without an AR observer, I can see from the trace output that it
fails with some PGError exception which is probably caught by ''rescue
nil'' statement (which in general is a bad way to handle
exceptions). Even the bulid output shows that it has attempted to do
something in the development environment. Before my patch the
dashboard shows two "Custom Build Artifacts" test.log and
development.log, and after my patch it only shows one!, namely
test.log. You can confirm this, right? This the case for any rails
project. When/if you can confirm this, you may ask yourself, why is
cruisecontrolrb producing a development.log. Nevertheless it is
interesting to see that the content of the development.log build
artifact has been executed on the test DB configuration, for example
the development.log contains "SET client_min_messages TO
''warning''",
but only my test DB configuration contains a "min_messages: warning"
setting, not development.

Even on your project a development.log is produced, right?

I think the reason the issue becomes fatal when using AR observers, is
that rails needs to connect to the database at rails boot time (that
is during load of environment configuration)

There is a difference between
$./script/console
Loading development environment (Rails 2.3.5)
>> RAILS_ENV=''test''
(irb):1: warning: already initialized constant RAILS_ENV
=> "test"
>> 
and 

$ ./script/console test
Loading test environment (Rails 2.3.5)
>> 

The first way is the way cruisecontrolrb does it (without my patch),
the second way is the correct way, and that is what my patch
ensures. The first way even gives a warning, namely that the RAILS_ENV
is prior to booting rails. Actually my patch is equivalent to
''RAILS_ENV=test ./script/console'' (setting the RAILS_ENV shell
environment variable prior to booting rails). Further the first way of
starting the console on my CI machine (where there is no development
DB) fails (now that I have introduced an AR observer) with the same
message as ccrb produced:
/var/lib/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/postgresql_adapter.rb:968:in
`initialize'':PGError: FATAL:  password authentication failed for user
"pegasus_dev"

So I think it is time for some refactoring of ccrb in general to
ensure that RAILS_ENV is set prior to booting rails, prior to running
rake tasks just isn''t early enough.
> It is just being called via Rake::Task[task_name].invoke, which
> should pass it along.  Plus, db:migrate obviously has no problems...
>
> Are you sure this isn''t a bug in your app or the specific version
of
> Rails you are using?
I am pretty sure... I am running the latests stable (2.3.5). I have
just followed standard rails guides, so the fact that rails connect to
the DB as early as during boot (but only when using AR observers), is
not my design and/or decision.

You can reproduce the problem, right? That also proves that it is not
only my app that is the problem.

Jarl