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.
Related
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.
I have a strange problem with rails migrations.
My db/migrate folder contains migration files and all worked fine.
But a few moment ago, I created a new file using rails g migration MigrationName, it generated a new file. then when i had runned rake db:migrate it rollbacks all and my schema version became 0.
Now when i run rake db:migrate it does nothing whereas db/migrate contains all my migrations.
i tried rake db:reset db:drop db:create db:migrate but no migrations was performed. However it says "migrations are pending run rake db:migrate RAILS_ENV=development" what i've done in vain.
I'm confused. Is anyone ever had this problem?
i've just tried RAILS_ENV=development rake db:migrate --trace and it returns:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
Running:
rake db:migrate:status
gives me:
database: database_development
Status Migration ID Migration Name
--------------------------------------------------
up 000 ********** NO FILE **********
down 20150613120151 Devise create users
down 20150613120734 Devise create admins
down 20150614114949 Create gender
down 20150614115642 Create events
down 20150614142610 Create multi events
I tried so many things:
- i dropped my database, restarted postgresql and run again rake db:setup db:migrate. rake db:migrate:status tells me that migrations are pending but it wont migrate.
it makes me crazy...
EDIT
I manually updated schema_migrations in database adding the timestamps
schema:load worked, but when i run rake db:migrate to check if its all good, it rolledback..
EDIT
if i manually fill schema_migrations version in database with timestamps, when i do rake db:schema:status they are all to up and my new migration to down, but if i do rake db:migrate it tries to revert as if i wanted to run rake db:rollback
So i fixed my issue.
In fact, i'm using dotenv to manage environment vars for development, and in my .env file i defined a var called VERSION to describe the API version...
That is the bug !
When i removed it, rake was able to migrate as expected.
I am not sure this will work for, but can you please try the following things,
First, drop tables
rake db:drop
Second, Delete/Remove db/schema.rb file
Third, create database
rake db:create
Fourth, run migration again
rake db:migrate
Please let me know if this help you a bit, good luck :)
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.
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!
I'm trying to test some environment-specific settings (middleware to be specific, but it doesn't seem to matter), but I'm having trouble getting the tests to run in the correct environment. The symptoms:
If I run ruby test/unit/my_test.rb, all is fine because the first thing it does is require test/test_helper.rb, which sets the environment to "test" and then loads the Rails environment.
If I run rake test, the first batch (functionals) run fine, but the second batch (units) fail. The failure is that ENV['RAILS_ENV] somehow gets unset between batches, then config/environment.rb sees that none is set and uses the default of "development". The environment is correct at the beginning of config/environment.rb and at the beginning of the configuration block in that file, but wrong by the end. I can tell by using a puts or by deleting config/development.rb causing it to not find the file.
If I run rake test:units, I get the same problem as the second batch of rake test (that is, all fail)
If I run rake test:functionals, I get the same as for rake test:units
If I run rake test RAILS_ENV=test or rake test:units RAILS_ENV=test or rake test:functionals RAILS_ENV=test, all is fine!
One thing I tried that doesn't work at all is the following:
# in Rakefile:
task :set_test_env { ENV['RAILS_ENV'] = 'test' }
Rake::Task[:test].prerequisites.unshift :set_test_env
# and similarly for other test tasks
I even tried creating a separate one of those :set_test_env tasks for each test task so that I was sure it would get called before each one instead of just once. Still no dice. It does get called, and the environment is correct at the beginning of config/environment.rb but something goes wrong inside.
I have no calls to set ENV['RAILS_ENV'] in my code anywhere.
To give you a full answer I would have to take a look at the code, but I'll try to give you some clues that might be helpful.
First of all rake test and all the other variants (test:units, test:functionals etc.) work as follows
Rake process is invoked and task test is executed in the current environment (which is development by default), that's why development.rb is always read.
The Rake task invokes the test loader in a separate child process (you can verify this with ps or pstree), this is where the test_helper.rb is sourced and environment is set to test.
When you run ruby test/unit/my_test.rb the first step is skipped, so it looks like the problem lies there. Maybe you do something in development.rb that has side effects for the subprocess?
I pretty much always want to force my tests to run themselves and their prerequisites in the "test" environment, especially when ENV['RAILS_ENV'] is set to any of the common defaults (to avoid catastrophic accidents), but I also want to be able to run tests on, say, an environment named "v_2_0_maint_test" or something like that by calling rake test:units RAILS_ENV=v_2_0_maint_test on the command line.
So I have a test_tasks.rake file that prepends a prerequisite onto each of the test tasks that I'm interested in. Since this prerequisite is prepended, any other prerequisites (e.g. db:test:prepare, db:fixtures:load) run in the same environment. This claims the virtue of affecting only the tests you want to affect, and their prerequisites.
namespace :test do |n|
[ n[:units], n[:functionals], n[:integration] ].each do |t|
t.prerequisites.unshift(:set_test_env_dammit)
end
task :set_test_env_dammit do |t|
if [ nil, "", "development", "staging", "production" ].index ENV['RAILS_ENV']
RAILS_ENV = "test"
end
end
end
At the top of the test_helper.rb file I have the code
ENV["RAILS_ENV"] = "test"
If you do not have that line then the system problem would run in the default environment (i.e. development).
Search through your entire project for RAILS_ENV and its variants. See if you set it somewhere in your application or in your tests.
Also, what platform are you running on? Can you run tests on another machine and see if the results are the same?
If this is a relatively recent development and you're using a RCS like Git or SVN, you should look through the recent commits, and if you're specifically using Git, you should look into git bisect. If you're not using an RCS, you should be.
If this is truly a fresh app problem, then it's probably a problem with your environment.
What plugins and gems do you have installed/configured? Can we see the backtrace?
I do not actually believe that you have an issue here at all. I believe that at some time you spotted that your rake task was actually hitting the development environment and you started to try and work out why that was the case. You then added a line within the development config file to raise an exception and this is why your rake tests are failing.
If you remove the line that is raising an exception then you may find that the tests all run succesfuly.
If you try the following you may find that it explains the issue.
Set the environment to development (Just for purposes of the trace)
export RAILS_ENV=development
Remove all lines that artificially
raise exceptions in your environment
files.
Add the following line to the end of
each file in config/environments
puts "**** In #{ENV['RAILS_ENV']} environment config ****"
Add the following line to the test/test_helper.rb just below the line that sets the environment to test.
puts "**** Loading test helper **** Environment = #{ENV['RAILS_ENV']}"
Run rake using the trace option to watch the tasks execute with a trace of the currently active environment.
rake -t test
Examine the output to determine where your environment is not set correctly.
Run the tests again but this time set the environment directly before running the tests using
export RAILS_ENV=test
If you really do have an issue then perhaps you should post up the output of the rake -t with the tracing code in.
This is the output of my tests in a brand new project with some minimal testing in place. You will notice that before the actual tests are run the environment is always "test"
** Invoke test (first_time)
** Execute test
** Invoke test:units (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
**** In development environment config ****
** 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:units
**** Loading test helper **** Environment = test
**** In test environment config ****
Loaded suite /Library/Ruby/Gems/1.8/gems/rake-0.8.3/lib/rake/rake_test_loader
Started
.
Finished in 0.071771 seconds.
1 tests, 1 assertions, 0 failures, 0 errors
** Invoke test:functionals (first_time)
** Invoke db:test:prepare
** Execute test:functionals
**** Loading test helper **** Environment = test
**** In test environment config ****
Loaded suite /Library/Ruby/Gems/1.8/gems/rake-0.8.3/lib/rake/rake_test_loader
Started
.....
Finished in 0.133776 seconds.
5 tests, 6 assertions, 0 failures, 0 errors
** Invoke test:integration (first_time)
** Invoke db:test:prepare
** Execute test:integration