Currently, rake db:schema:load is run to setup the database on CircleCI. In migrating from using schema.rb to structure.sql, the command has been updated to: rake db:structure:load.
Unfortunately, it appears to hang and does not return:
$ bin/rake db:structure:load --trace
** Invoke db:structure:load (first_time)
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:structure:load
WARNING: terminal is not fully functional
set_config
------------
(1 row)
(END)rake aborted!
Interrupt:
<STACK TRACE>
bin/rake:9:in `<main>'
Tasks: TOP => db:structure:load
Too long with no output (exceeded 10m0s)
Found someone else with the same issue on CircleCI, no answers though.
This seems to have something to do with the psql client's output to the terminal expecting user input:
set_config
------------
(1 row)
(END) <--- like from a terminal pager
Not exactly a proper solution, but a workaround in .circleci/config.yml:
jobs:
build:
docker:
- image: MY_APP_IMAGE
environment:
PAGER: cat # prevent psql commands using less
Ran into something similar recently on CircleCI with Postgres 11.14.
Here is the thread about it there: https://discuss.circleci.com/t/postgres-failing-with-upgrading-from-11-6-to-11-14/42932/2
Basically needed to add to the Ruby environment section in the Circle CI config.yml:
PSQL_PAGER: ''
Thanks to #swrobel for the fix.
Related
I'm running a (previously working fine) seed file like so:
I check to see if there are pending migrations with rake db:migrate:status and all migrations are "up".
For additional context, here's what led me to this point:
Working in 6 year old Rails Code
Start a branch for feature "A"
Wrap feature "A". Checkout new branch for Feature "B"
Master --> "A" --> "B"
Finish feature "B" + commit
Checkout "A" for refactoring
Add column to migration for "A" (nothings been merged with master yet, so I figure I can drop and rebuild my dev db no problem WRONG)
Wrap refactoring for "A" + Commit
Checkout Branch "B"
9 Merge "A" into "B"
Drop DB
Create DB with bin/rake db:create db:schema:load All good
Run rake db:seed and nothing happens.
Run with trace and get the error you see above.
Have no idea what's causing this.
More Context
-Ruby 2.3.1
-Rails 4.2.7.1
-Postgresql 9.6.2
It doesn't look like you actually have a problem; abort_if_pending_migrations just happens to be the last trace line that even a successful seed outputs. A fully-working Rails env on my machine spits out the same output, but works just fine (complete with 0 error code):
$ be rake db:seed --trace
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
$ echo $?
0
For the record, it's expected for db:seed to normally print no output.
I have a script/cibuild script, which I run on Semaphore Hosted CI Service), that contains…
time bundle exec rake db:setup db:test:prepare --trace; echo
… to setup the database and check if are there any pending migrations, but for some reason this won’t work not even on my development machine.
Striping down script/cibuild’s contents boils down to this:
export RAILS_ENV=test
export RACK_ENV=test
# options to rake 'spec' task
export SPEC_OPTS='--color --format documentation --backtrace spec'
echo "Installing dependencies..."
time bundle install --deployment; echo
echo "Setting-up database..."
time bundle exec rake db:setup db:test:prepare --trace; echo
echo "Running tests..."
time bundle exec rake spec --trace; echo
Build will eventually fail with the following trace on Semaphore:
Running tests...
** Invoke spec (first_time)
** Invoke test:prepare (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:abort_if_pending_migrations
You have 10 pending migrations:
20130418144736 CreateUsers
20130424134725 CreateCollections
20130506124127 AddStaffToUsers
20130513115848 CreateResourceTypes
20130513140804 InstallHstore
20130513141924 CreateResources
20130513144332 AddCredentialDataToUsers
20130523155851 RenameSubscriptionDataInResource
20130531110125 AddProfilePictureToUser
20130722101545 AddEmailIndexToUser
Run `rake db:migrate` to update your database then try again.
Now it seems to me that the problem may not be at db:setup db:test:prepare line, but instead when rake spec is run. I am not sure.
In any case if I run in my development machine…
rake db:drop:all
rake db:setup db:test:prepare
… I will end up with an empty test database (“empty” as in no tables, etc.) whereas…
rake db:drop:all
rake db:setup
rake db:test:prepare
… will create also test database, as expected.
One might think as if I didn’t run rake db:migrate at some point (hence 10 pending migrations), but I am pretty confident that this isn’t the case. Although I don’t have a db/schema.rb file, rails should apply all the migrations to get to the final database schema just fine.
Any ideas, please? Thank you.
Update:
I kind of suspect that the issue might be related to setting RACK_ENV and/or RAILS_ENV environment variables to test. This seems to mess things up a bit.
When i try and preform a rake I get the following. I've tried a few fixed like imploding and reinstalling my rvm - ruby (v1.9.3-p125) but nothing seems to be working. Any ideas?
rake db:seed --trace
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
rake aborted!
stack level too deep
/Users/rm/.rvm/gems/ruby-1.9.3-p125#global/gems/rake-0.9.2.2/lib/rake/task.rb:162
Tasks: TOP => db:seed
if I try and run a rake db:reset --trace
-- initialize_schema_migrations_table()
-> 0.0025s
-- assume_migrated_upto_version(20120803181844, ["/Users/rossmcnairn/rails/search/db/migrate"])
-> 0.0218s
** Invoke db:structure:load_if_sql (first_time)
** Invoke db:create
** Execute db:structure:load_if_sql
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment
** Execute db:abort_if_pending_migrations
rake aborted!
stack level too deep
/Users/rossmcnairn/.rvm/gems/ruby-1.9.3-p125#global/gems/rake-0.9.2.2/lib/rake/task.rb:162
Tasks: TOP => db:setup => db:seed
Ive checked that my bundle exec version and my regular rake versions match.
rake --version
rake, version 0.9.2.2
bundle exec rake --version
rake, version 0.9.2.2
Any help would be greatly appreciated!
Updating OSX is known to give issues in rubies, you should recompile all your rubies:
chown -R $USER: $rvm_path
rvm get head
rvm reinstall 1.9.3-p125
rvm all-gesmsets do rvm gemset pristine
Also note that any other compiled stuff like libraries needs recompilation, this includes homebrew, macports, rvm pkg and any packages you have compiled manually.
** Execute db:abort_if_pending_migrations
rake aborted!
Did you try to run your migrations?
This may be obvious but it took me a few hours. I unwittingly created a class method for the model called create, which is the same as ActiveRecord create. So my seed file has circular reference.
I just kept staring at the seed file and wonder why I get the error while I was able to run it twice before (before adding the class method). Moral of the story: naming is important.
I'm trying to run a migration on my Rails app, by using rake:db migrate --trace and I get the following output:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
It then doesn't do anything after this. If I Ctrl + C I get some errors, but I'm not sure I understand them. Is there any way I can step through and debug the migration process so I can see when it hits the problem migration?
its (space between rake and db).
rake db:migrate
try for a overview of rake db tasks:
rake -T db
Try
bundle exec rake db:migrate --trace
I realized the reason this was not firing was it was initializing a sleep command waiting on something that wouldn't be initialized via rake (the app had to be running). So, rake was not the culprit this time!
Just wondering if there's a way to run Rails tests without dropping the database. I'm currently only executing unit tests and am using the following rake command to do so: rake test:units.
Thanks for the help in advance!
Just in case this is relevant:
Rails 3
Ruby 1.8.7 (MRI)
Oracle 11g Database
activerecord-oracle_enhanced-adapter
In Rails 5 (and possibly earlier versions), just comment-out the following line in spec/rails_helper.rb:
ActiveRecord::Migration.maintain_test_schema!
This will prevent rake test or rspec from attempting to drop your test DB. You'll need to run migrations manually as well.
For Rails 5.2 this behaviour can be modified setting maintain_test_schema to false in test/test_helper.rb before importing rails/test_help:
ActiveRecord::Base.maintain_test_schema = false
require "rails/test_help"
rails/test_help will check the value of maintain_test_schema to decide if it has to drop/create/migrate the test database or not.
After doing some research, I have found that there isn't a way to do this. The test rake tasks will always drop the database, even when providing the TEST= option as Bohdan suggests.
By using the --trace option, this can be proven. Here is the output:
$ rake test:units TEST=test/unit/post_test.rb --trace
(in /Users/johnnyicon/Development/ror/test-app)
** Invoke test:units (first_time)
** Invoke test:prepare (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
** Execute test:prepare
** Execute test:units
Reading through the Ruby on Rails Guides for Testing, it describes what some of these rake tasks mean. The one to pay particular attention to is the db:test:load task, which you see on the 7th line from the bottom of the output as ** Execute db:test:load. The guides say the following about this task:
Recreate the test database from the
current schema.rb
So even if I were to execute the unit tests one by one as Bohdan suggests, the rake task would still recreate the database. Not the answer I was hoping for, but it isn't a problem anymore.
The reason I was asking to begin with was because I did not have access to another database to use for testing, so I was using my development database for testing as well. But since then, I've been able to get another database dedicated for testing.
Thanks anyway Bohdan! I appreciate the help!
This is a rather old post that does the monkey patching of overriding purge/load tasks:
http://www.pervasivecode.com/blog/2007/09/22/making-rails-raketest-not-drop-your-pgsql-database/
For those looking for a way to skip Rails' default behavior, try adding this to your Rakefile:
Rake::Task["db:test:prepare"].clear
Rake::Task["db:test:load"].clear
Rake::Task["db:test:purge"].clear
Could you not write a custom Rake task that monkey patched the Rake db:test:load task to do nothing?