Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Rails env = test possibly still not being set properly in 3.2.8.rc2? #7271

envygeeks opened this Issue · 10 comments

5 participants


I don't know if this is related to #7174, #7175 or #7227 however with 3.2.8.rc2 I still have problems with it setting environment when it comes to rake spec. I can do RAILS_ENV=test rake db:migrate just fine which shows that my database is accessible, I can run rspec just fine, I can also use guard w/spork and it still work just fine, however with rake spec it fails no matter what, even if I do ENV['RAILS_ENV']= 'test' in my spec_helper.rb, even if I do RAILS_ENV=test rake spec or anything... it fails.

#~ RAILS_ENV=test rake db:migrate
==  CreateEnvygeeks: migrating ================================================
# Migration info goes here, removed for no reason other then not needed.

#~ RAILS_ENV=test rails c
Loading test environment (Rails 3.2.8.rc2)
[1] pry(main)> User.all
#=> User Load (73.8ms)  SELECT "users".* FROM "users" 
#=> []

[1] pry(main)> ActiveRecord::Base.connection.current_database
#=> (132.7ms)  select current_database()
#=> "f72e"

#=> "f72e"

#~ cat config/database.yml
  adapter: postgresql
  encoding: unicode
  pool: 5
  port: 5432

#~ rake spec
** Invoke spec (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
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:test:purge
rake aborted!
FATAL:  permission denied for database "postgres"
DETAIL:  User does not have CONNECT privilege.
/home/jordon/.rvm/gems/ruby-1.9.3-p194@envygeeks/gems/activerecord-3.2.8.rc2/lib/active_record/connection_adapters/postgresql_adapter.rb:1213:in `initialize'

I don't think it is a Rails bug. Seems that your user at the database doesn't have the connect privilege.


To confirm just run rake db:test:purge. This can be an issue with that task


@rafaelfranca Actually both of us were wrong (well you were right in a sense because you did guess that it did not have permissions,) after some more investigation it's because Rails assumes that all testing databases are local so it was trying to remove the database (albeit the wrong one) it was trying when we actually hold our testing database on servers designed to be exactly like production so there is auth and the whole 9 yards including inability to do 'system level stuff'. Perhaps rails could be less assumptious in Rails 4 and check the hostname to see if it's localhost or not?


I don't think we can. This there nothing with the localhost, the db:test:prepare task need that the database user configured in the test environment needs to have privilege to drop the database and create again. This will occur in localhost too.


@envygeeks try adding a duplicate "test" environment that connects with higher db privileges and use that just for running db setup/migration tasks.


@envygeeks Could this be an issue with your pga_hba.conf file? I would check the auth_method defined in there. However, still a little mysterious that you are able to run the other tasks. Give it a shot.


@avit tried, didn't work sadly. @jasdeepsingh It turned out that it was because it was trying to remove the database and create a new one. @rafaelfranca Although I would love it if Rails did what I mentioned above but it would be equally as nice if it just rescued out and continued on or had an option to disable the dropping and creating of databases... I say it would be nice if it rescued out because if there really is a connect issue then it should/would be brought up later either before the tests start when they try to connect or during.


Yes, this can be improved. I'll leave this issue open. If anyone want to open a pull request, please go ahead.


Here is what I did to go around this problem:-
Create a ssh tunnel in the background as ssh -C -N -L 3307:destination.ip:3306 username@remote.ip

and in the database.yml

adapter: mysql2
encoding: utf8
reconnect: true
database: XXX_test
pool: 50
username: XXXXX
password: XXXXX
port: 3307


I'm closing this issues since it is more a feature request that a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.