Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
envygeeks opened this Issue · 10 comments

5 participants

@envygeeks

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"

[2] pry(main)> ENV['WESTAMZ_ENVYGEEKS7_POSTGRES_DATABASE']
#=> "f72e"

#~ cat config/database.yml
test:
  adapter: postgresql
  encoding: unicode
  pool: 5
  database: <%= ENV['WESTAMZ_ENVYGEEKS7_POSTGRES_DATABASE'] %>
  username: <%= ENV['WESTAMZ_ENVYGEEKS7_POSTGRES_USERNAME'] %>
  password: <%= ENV['WESTAMZ_ENVYGEEKS7_POSTGRES_PASSWORD'] %>
  host: <%= ENV['WESTAMZ_ENVYGEEKS7_POSTGRES_HOSTNAME'] %>
  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'
@rafaelfranca
Owner

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

@rafaelfranca
Owner

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

@envygeeks

@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?

@rafaelfranca
Owner

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.

@avit

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

@jasdeepsingh

@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.

@envygeeks

@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.

@rafaelfranca
Owner

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

@midglide

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

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

@rafaelfranca

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.