Chad Woolley <thewoolley...@gmail.com> writes: > On Mon, Mar 8, 2010 at 9:04 AM, Jarl Friis <j...@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 _______________________________________________ Cruisecontrolrb-users mailing list Cruisecontrolrb-users@rubyforge.org http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
