[Cruisecontrolrb-users] question on db:test:purge behavior

[Yuri Gadow]

Had the same problem with our application, i.e., cruisecontrol.rb
"rake test" attempts to create the table in the ninth migration over
again. Commented out "rake db:test:purge" in tasks/cc_build.rake:49
and all is well so far.

Can see the problem output at
https://developing.givekind.org/cruisecontrol/builds/givekind_app/63.9

In case it makes a difference, in our app's environment.rb:
config.active_record.schema_format = :sql

and instead of the "cruise" command, cruise is started using
mongrel_rails start --prefix=/cruisecontrol -p 3333 -d -e test

we started with -e production, but then the app's rake migrations try
to go to the production db, which doesn't exist, instead of test.

Yuri

> Alexey Verkhovsky averkhov at thoughtworks.com
> Wed Mar 21 16:13:44 EDT 2007
>
> If you want to get to the bottom of it, try to run the builder with
> --trace option, like this:
>
> cruise build YourProject --trace
>
> and force the build. You will get a stack trace out of Rake that will tell
> you what task is being executed.
>
> Otherwise, as the documentation says "if defaults do not work for you,
> instead of trying to bend your app into working with CC.rb defaults, just
> create a custom 'cruise' task in your build and be done with it".
>
> Alex
>
>
>> Matthew Wright <matt at wrighters.net>
>> 03/21/2007 07:18 AM
>>
>> I saw cc.rb yesterday and gave it a try, what a nice project.  Having
>> setup 2 large cc (java) projects before, I have to say this is much
>> easier to setup and has a great interface.  Great job.
>>
>> In order to get my builds to work, I had to override the default cc
>> behavior and remove the db:test:purge from the build.  If I run the
>> following in my project/work directory, the build succeeds:
>>
>>   export RAILS_ENV=test
>>   rake db:test:purge && rake db:migrate && rake test
>>
>> If I run it via cc, I get this:
>>
>> /usr/bin/ruby1.8 -Ilib:test "/usr/lib/ruby/gems/1.8/gems/rake-0.7.2/
>> lib/rake/rake_test_loader.rb" Mysql::Error: Table 'plan_days' already
>> exists: CREATE TABLE plan_days (`id` int(11) DEFAULT NULL
>> auto_increment PRIMARY KEY, `plan_id` int(11) DEFAULT NULL, `day` int
>> (11) DEFAULT NULL) ENGINE=InnoDB
>> etc., etc.
>>
>> This is a table created in the 9th migration, so if the migrations
>> were running twice because schema_info wasn't being updated, I would
>> expect more errors than this one.
>>
>> I thought maybe a foreign key was preventing a migration from
>> dropping a table or something, but I added drops in all the down
>> methods of my migrations where fks are created.  Just wondering if
>> anyone else has seen this.  .
>>
>> Matt