3.2.7 rake test sets the environment to development #7175

Closed
dchelimsky opened this Issue Jul 27, 2012 · 31 comments

Projects

None yet
@dchelimsky

See #7174 for background.

rake test shells out to a new process (because it is invoked in the development environment but tests need to be run in a different environment).

Before 3.2.7, Rails appeared not to set the environment in the subshell, allowing you to put ENV["RAILS_ENV"] ||= "test" in test/test_helper.rb. This way the default behavior was that it would run in the "test" environment, but you could write custom rake tasks that set it to different test environments (e.g. "test" for local runs and "ci" on a ci server).

With Rails 3.2.7, by the time test/test_helper.rb is loaded the environment has already been set to development, so the default behavior (if you're using ENV["RAILS_ENV"] ||= "test"instead of ENV["RAILS_ENV"] = "test") is to run the tests in the development environment.

@shenie
shenie commented Jul 27, 2012

I am able to use rail 3.2.7 and have test run against test DB by putting this in *_helper.rb

RAILS_ENV = (ENV["RAILS_ENV"] || 'test')

I will probably still keep the following around tho.

ENV["RAILS_ENV"] ||= 'test'

EDIT

Better make that RAILS_ENV = 'test' without the "ENV['RAILS_ENV'] || "

@rafaelfranca rafaelfranca added a commit that closed this issue Jul 27, 2012
@rafaelfranca rafaelfranca Only require the `:rails_env` task where is needed.
`:rails_env` tasks is not needed in all the tasks that depends of
`load_config`, only in the tasks that uses `Rails.env`.

Since `:rails_env` task set the `Rails.env` to be "development" if it is
not set we don't need the `||` statements too

Fix #7175.

Conflicts:
	activerecord/lib/active_record/railties/databases.rake
f1afd77
@rafaelfranca rafaelfranca added a commit that referenced this issue Jul 27, 2012
@rafaelfranca rafaelfranca Only require the `:rails_env` task where is needed.
`:rails_env` tasks is not needed in all the tasks that depends of
`load_config`, only in the tasks that uses `Rails.env`.

Since `:rails_env` task set the `Rails.env` to be "development" if it is
not set we don't need the `||` statements too

Fix #7175.
4b8b8c1
@rafaelfranca
Member

@dchelimsky these commits should fix the issue.

Thank you to report.

@dchelimsky

Confirmed. Issue fixed on the 3-2-stable and master branches.

@dim
dim commented Jul 27, 2012

This is a critical issue, as it wipes the development database as part of a rake spec run. This will require a Rails 3.2.8 release.

@tenderlove
Member

Yup. I think @rafaelfranca has put this on the 3-2-stable branch, so it will be in 3.2.8. :)

@dchelimsky

@tenderlove do you agree this needs to be released very soon?

@rafaelfranca
Member

Yes, we agree.

@tenderlove
Member

@dchelimsky I'll cut an RC on Monday. Let's have more people try the RC this time! :-D

@dgm
dgm commented Jul 28, 2012

@tenderlove most of us affected by this probably need more time to even know that a RC was in the pipeline! I found out about it from news aggregators that there was a release, but never knew about an RC.

My test suite smashed my dev database thanks to this bug and ... I bet the mail tests failed for the same reason.

@steveklabnik
Member

I feel like there's another ticket that talks about this, but I can't find it at the moment.

@sekrett
sekrett commented Aug 1, 2012

@tenderlove which of the Mondays you were talking about? ;) DatabaseCleaner users hate the 3.2.7 release.

@tenderlove
Member

Sorry, I'm really too busy to take care of this. :(

@spastorino will be handling the 3.2.8 release.

@spastorino
Member

I'm releasing this today

@jcoyne
jcoyne commented Aug 2, 2012

I'm still having this issue with rails 3.2.8.rc1

@rafaelfranca
Member

could you do me a favor?

run rake --trace with Rails 3.2.8.rc1 and put here

@jcoyne
jcoyne commented Aug 2, 2012

@rafaelfranca Looks good now. See #7174 Thanks for your help.

@rafaelfranca
Member

No problem. Thank you to report back.

@PiotrMisiurek

I have the same issue with Rails 4.0.0.beta

@carlosantoniodasilva

@PiotrMisiurek running current master or a specific ref? If it's present on master, we need to fix asap.

@alindeman

@PiotrMisiurek running current master or a specific ref? If it's present on master, we need to fix asap.

I'm seeing this on a Rails 4 app as well. I'll update with more details soon.

@alindeman

Yes, this was reintroduced as a problem in master at b3125c8 (/cc: @steveklabnik)

I don't yet know how to fix it, but that's where my bisect led me to.

I'll continue digging myself, but wanted to post info as soon as I knew it in case someone is able to fix it better/faster.

@alindeman

I had pasted the wrong commit at first. I edited the comment above to fix it.

@steveklabnik
Member

Hmmmm. yeah, I'm not sure whtat's up.

@alindeman

Here's what I think is happening:

Rakefile in a default Rails app loads the application:

# Add your own tasks in files placed in lib/tasks ending in .rake,
# for example lib/tasks/capistrano.rake, and they will automatically be available to Rake.

require File.expand_path('../config/application', __FILE__)

config/application.rb includes this code:

# Assets should be precompiled for production (so we don't need the gems loaded then)
Bundler.require(*Rails.groups(assets: %w(development test)))

Rails.groups depends on Rails.env, so as of b3125c8, ENV['RAILS_ENV'] is set to "development" by default. Actually, there's a lot of code that touches Rails.env as the app is booting, but that's some of the first.

So when rake forks off an rspec process, it inherits that RAILS_ENV value. spec_helper.rb by default only sets RAILS_ENV if it's not already set (because some folks like to use a different environment for things like CI), so we end up running specs in "development".

I used RSpec as an example, but this would be problematic even for Test::Unit/MiniTest if ENV['RAILS_ENV'] ||= "test" were used in a test helper.

@alindeman

Is there a way to fix #8025 without setting an environment variable that leaks out through to tasks spawned by rake?

@alindeman

I sent in #8574 as a possible solution. Let me know what you think.

@alindeman alindeman added a commit to alindeman/rails that referenced this issue Dec 21, 2012
@alindeman alindeman Revert "Make sure that RAILS_ENV is set when accessing Rails.env"
This reverts commit b3125c8.

* It is not desirable to set `ENV['RAILS_ENV']`; otherwise, it will leak
  through to rake tasks such as `rake test` or `rake spec`. See #7175
  for more details.
33b3fa6
@pencilcheck

In 3.2.13 it stills having this issue, where RAILS_ENV has already being set when running rspec, so ENV['RAILS_ENV'] ||= 'test' will return 'development'

@dmathieu

@zetlan: I just tried your test case with 4.0.0.

development.log is created when creating the app, not when running the tests. And a test.log is also created, and that's the file rails is writing into.

If I remove the development.log file and rerun the tests, it's not recreated.

@zetlan
zetlan commented Oct 31, 2013

I didn't remove my comment quickly enough – there was a stray export RAILS_ENV="development" in a shell script referenced by my profile. So this is a seat-to-keyboard interface failure.

On Oct 31, 2013, at 11:28 AM, Damien Mathieu notifications@github.com wrote:

@zetlan: I just tried your test case with 4.0.0.

development.log is created when creating the app, not when running the tests. And a test.log is also created, and that's the file rails is writing into.

If I remove the development.log file and rerun the tests, it's not recreated.


Reply to this email directly or view it on GitHub.

@dmathieu

No problem. 🤘

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment