Skip to content
This repository

3.2.7 rake test sets the environment to development #7175

Closed
dchelimsky opened this Issue July 26, 2012 · 31 comments
David Chelimsky

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.

Andy Shen
shenie commented July 26, 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'] || "

Rafael Mendonça França rafaelfranca closed this issue from a commit July 27, 2012
Rafael Mendonça França 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
Rafael Mendonça França rafaelfranca closed this in f1afd77 July 26, 2012
Rafael Mendonça França rafaelfranca referenced this issue from a commit July 27, 2012
Rafael Mendonça França 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
Rafael Mendonça França
Owner

@dchelimsky these commits should fix the issue.

Thank you to report.

David Chelimsky

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

Dimitrij Denissenko
dim commented July 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.

Aaron Patterson
Owner

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

David Chelimsky

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

Rafael Mendonça França
Owner

Yes, we agree.

Aaron Patterson
Owner

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

dgm
dgm commented July 27, 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.

Steve Klabnik
Collaborator

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

Alexander Zubkov

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

Aaron Patterson
Owner

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

@spastorino will be handling the 3.2.8 release.

Santiago Pastorino
Owner

I'm releasing this today

Justin Coyne

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

Rafael Mendonça França
Owner

could you do me a favor?

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

Justin Coyne

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

Rafael Mendonça França
Owner

No problem. Thank you to report back.

David Chelimsky dchelimsky referenced this issue in rspec/rspec-rails August 06, 2012
Closed

Does not work with Rails 3.2.7 #577

PiotrMisiurek

I have the same issue with Rails 4.0.0.beta

Carlos Antonio da Silva

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

Andy Lindeman

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

Andy Lindeman

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.

Andy Lindeman

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

Steve Klabnik
Collaborator

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

Andy Lindeman

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.

Andy Lindeman

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

Andy Lindeman alindeman referenced this issue from a commit December 20, 2012
Commit has since been removed from the repository and is no longer available.
Andy Lindeman

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

Andy Lindeman alindeman referenced this issue from a commit in alindeman/rails December 20, 2012
Andy Lindeman 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
Penn Su

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'

Damien Mathieu
Collaborator

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

Scott Zetlan
Damien Mathieu
Collaborator

No problem. :metal:

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.