Reputation: 3373
I'm working with a large Rails application, and i've been tasked with disabling rake tasks that could be harmful if run on our production environments, such as db:migrate, reset, etc. However i'm not sure what the best course of action here is.
So far my solution is to put a statement like this at the top of the databases.rake task
if ENV['RAILS_ENV'] == 'development' || ENV['RAILS_ENV'] == 'test'
Now obviously this disables all the database rake tasks for all environments but development and test. However, i feel like this is hacky and I dont like it. Can anyone think of a better way to solve this problem, or does this solution pose any greater problems that I may not be realizing?
EDIT: A side question to a problem i've encountered. When i set my RAILS_ENV to 'production' via
export RAILS_ENV=production
That worked fine, however i need to set my environment back to the default ' ' environment. When I try
export RAILS_ENV=
I get an error
No such file or directory - project_path/config/environments/.rb
Does anyone know how to reset the environment back to default?
Upvotes: 3
Views: 652
Reputation: 3766
http://kjvarga.blogspot.com/2009/12/rakefile-mods-prevent-destructive-rake.html looks promising.
Upvotes: 0
Reputation: 5357
As for your side question, the default environment is "development". So you might try:
export RAILS_ENV=development
What you're doing is assigning an empty string to RAILS_ENV (which is different from it not existing at all, which is what you want). To accomplish this, try:
export -n RAILS_ENV
Also, if you find yourself switching environments like this for one-shot commands (like rake tasks and such), you might try NOT exporting the variable, just defining it when calling the command:
RAILS_ENV=production rake db:migrate
This way, after the command is completed, you don't have an exported RAILS_ENV variable; think of it as being defined just for that particular invocation of rake (or whichever command you wanted).
Upvotes: 1