[Cruisecontrolrb-users] rake build issue related to foreign key constraints?

[Patrick Joyce]

Thanks for your response, Neil.  My problem is somewhat different but
I imagine that your solution may help someone else.

It turns out that there is a known issue with Rails leaving fixture
data in the DB after a TestCase runs.
(http://dev.rubyonrails.org/ticket/2404) Therefore this actually was a
Rails issue, not a cruisecontrol.rb issue. My tests would pass when
running "rake test" from the command line because "rake test" builds
the test DB schema from schema.rb. Schema.rb is created by
db:schema:dump which ignores foreign keys.

So I've been running my tests against a DB without the foreign keys.
The issue only showed up with cruisecontrol because cruise builds the
test DB directly from the migrations.

For now, I've created a :cruise rake task that builds in the same way
as "rake test" (without foreign keys). I set up dev and test databases
for cruisecontrol and then invoke the rake tasks "db:migrate" and
"test" in my :cruise task.

desc 'Continuous build target'
task :cruise do
  Rake::Task['db:migrate'].invoke

  Rake::Task["test"].invoke
end

This runs the migrations against the development DB, moves the schema
to the test DB without the foreign keys, and runs the tests.

When I figure out how to properly handle fixtures with foreign keys
I'll change the task to reflect it.

Thanks again for all your help.

- Patrick Joyce

On Nov 8, 2007 2:53 PM, Neill Zero <neillzero at yahoo.co.uk> wrote:
>
>
>
> Patrick Joyce wrote:
> >
> > Did anyone ever find a solution to this? My tests pass when I run "rake
> > test" in the work directory but when cc.rb runs the tests I get an error
> > on every test after the test in which the Schedules fixture is loaded. All
> > tests before the schedules fixture is loaded pass. It seems as though that
> > table isn't being cleared. Any idea why this would happen?
> >
>
> Hi Patrick,
>
> I had a similar but not identical issue some time ago.  I traced it to the
> fact that rake, under the standard cruise build task, was not executing
> db:test:purge every time it was "invoked".  In my case, my migrations loaded
> seed data into the tables, which was not then purged before tests ran.
> Fixture loading then caused FK constraint violations.  At the time, I worked
> around the issue with a custom build task to use under cruise which did
> almost the same but forced a purge at the critical point.
>
> Here's the detail of what I found, and the workaround I used.  Hopefully it
> is also applicable in your situation.
>
> To understand the problem, I needed to understand what 'rake test' was
> doing.  I've put a diagram of the dependencies at
> http://abstractplain.net/blog/?p=1019.
>
> If we look at a trace of the test task in a stand-alone rake invocation,
> side-by-side with the  cruise build task, and if we look only at what tasks
> are actually being *executed* (rather than invoked) we have the following
> (view it with a fixed width font):
>
> rake stand-alone                  cruise build
> ----------------------------------------------------------
>                                  Execute cc:build
>                                  Execute environment
>                                  Execute db:test:purge
>                                  Execute db:migrate
>                                  Execute db:schema:dump
> Execute test                      Execute test
> Execute environment         <
> Execute db:test:prepare           Execute db:test:prepare
> Execute db:schema:dump      <
> Execute db:test:purge       <
> Execute db:test:clone             Execute db:test:clone
> Execute db:schema:load            Execute db:schema:load
> [runs tests]                      [runs tests]
>
> You can see that on the cruise side, the tasks 'environment',
> 'db:schema:dump' and 'db:test:purge' are not called when running the test
> task!  If you look at a fuller trace, you'll see it is being invoked (the
> db:test:clone requires it) but not executed!  Rake thinks this declared
> "dependency" has been met, because rake called them earlier in the cruise
> task; cruise invokes "db:test:purge" explicitly on line 49 of
> tasks/cc_build.rake (in cruise v1.1.0), and then 'db:migrate' a little
> later.
>
> So no purge is being done between cruise's running of migrations and running
> the tests.  In my case (where migrations populated some tables with seed
> data), I believe that this meant that when the tests ran, even before
> fixtures were loaded, there was data in the test db.  FK constraint
> violations occurred when the fixtures tried to delete and load their tables,
> due to the presence of these left-over records).  Do your migrations include
> seed data?
>
> I got around this issue by having cruise run a custom task.  Mine does
> almost exactly what cruise's standard build task does, but also ensures that
> purge is executed when it needs to be.
>
> A better solution might involve ensuring that cruise's calls to
> 'db:test:purge', 'db:migrate', and 'test' are have separate rake contexts.
>
> Finally, here's my custom task for building under cruise.  ( I've also
> posted it at: http://abstractplain.net/blog/?p=1024 )
>
> #This builds from migrations each time (slower, but more reliable).
> #Must then empty seed data before tests start to delete stuff, or FK
> constraints get violated.
> #NOTE: currently needs db:test:purgetwo to exist (just copy paste
> db:test:purge task)
> task :cruise do
>  ENV['RAILS_ENV'] = 'test'
>  puts "custom cruise task invoked.  env is hardcoded to test"
>
>  Rake::Task["environment"].invoke
>
>  #start from scratch with just the test db
>  Rake::Task["db:test:purge"].invoke
>
>  #necessary to reconnect, as purge drops database (and w mysql the conn)
>  CruiseControl::reconnect
>
>  #run all migrations from scratch.  slow but clean
>  Rake::Task["db:migrate"].invoke
>
>  #empty the db of data - migration has loaded seed data into the tables,
>  #which'll be deleted badly by test fixtures loader.
>
>  #NOTE: db:test:purgetwo is just a quick hack to force this
>  #identical action to be called again
>  #TODO: replace with the correct way to force execution of a task in rake
>  Rake::Task["db:test:purgetwo"].invoke
>
>  #necessary to reconnect, as purge drops database (and w mysql the conn)
>  CruiseControl::reconnect
>
>  #the migration has already done a schema dump
>  Rake::Task["db:schema:load"].invoke
>
>  success = Rake::Task["test"].invoke
>  success
> end
>
>
> #good luck, neill
>
> --
> View this message in context: http://www.nabble.com/rake-build-issue-related-to-foreign-key-constraints--tf4221922.html#a13654415
>
>
>
> Sent from the CruiseControl.rb - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>