Is there some way to disable all logging (whether from ActiveRecord, other parts of Rails, plugins, etc.) from a script running via script/runner? I've got a long data-loading script running, and it's generating an absurd amount of useless logging information. I'm not trying to change script/runner's environment (e.g., production, development, etc.)- the script currently needs to run in the "development" environment, and it's doing so without issue at the moment.
All I want to do is suppress all logging for the duration of the script's lifetime. From reading the docs, it looks like if I can get a handle to its Rails::Configuration I should be either able to set log_level to something other than :debug or set its logger to nil. Am I on the right track? If so, how do I get access to its Rails::Configuration object?
There are a couple of ways I can think of.
1) Set the log level so high that nothing will get logged:
ActiveRecord::Base.logger.level = Logger::Severity::UNKNOWN
See Logger::Severity for more about that. UNKNOWN is the highest.
"level" is just a number, so it can be set to Logger::Severity::UNKNOWN + 1 if you feel paranoid. :)
2) Send the output to /dev/null.
ActiveRecord::Base.logger = Logger.new('/dev/null')
(I'm assuming that there is just one instance of Logger that is used by Rails, and that it's the one you get via ActiveRecord::Base.logger. If there are more of them you'd have to find them and fiddle with them also.)
If you don't like these you might find something else by reading the Logger docs.
The settings are in your config/environments/*.rb files, which override the default for environment.rb. When it does "Rails::Initializer.run do |config|" it's running with the config object. I'm fairly sure you can change either to suite your needs, but I'm not sure how you'd pass it a flag saying it was a script/runner script currently executing.
(I know you said your not interested in changing the environment, but I thought I'd throw out there that you could create a new env for a dataload script that has most of the same settings but no logging fairly easily)
Related
I'm working on a Rails application and I am attempting to organize my secret_key_base and related important secrets (Think API keys, database credentials, etc.)
I am trying to find a way to setup something like the following, under /config
/config
credentials.yml.enc
master.key
/config/credentials
development.yml.enc
development.key
production.yml.enc
production.key
test.yml.enc
test.key
First Question:
Is it that secret_key_base exists in /config/credentials.yml.enc, which is loaded (first?) and then the credentials are loaded for the environment rails is running in? Or should I create a different secret_key_base for each environment?
Second Question:
No matter what I do, when I run in development or test, tmp/development_secret loads first. In addition, whenever I try to access my secrets in development, (Rails.application.secret_key_base) as referenced here: What's the correct way of defining secret_key_base on Rails 6, I run into an issue where I only ever receive nil when looking for secrets I've defined in my development.yml.enc, which I assume is because it's not loading anything in that file, it's going to tmp/development_secret and not finding anything else (Maybe I'm wrong.)
Goals:
Stop tmp/development_secret from being created, and instead access
secrets using the specific .yml.enc file depending on the
environment.
Understand why /config/credentials.yml.enc exists if it doesn't
load in all the environments. If it doesn't, then it isn't clear when it loads.
Why?
Using config/database.yml as an example, I want to store different creds for each environment, but none of them in version control. (I want nobody but a few to have production.) However, I want to access them the exact same way in all of my environments. Not having creds load in production because of an issue with a .yml file will crash my app, so I don't want to load them differently in test/development.
Put together a blog post about this because searching for documentation on this feature is painful. It's a really easy thing because then only the master.key, and production.key would need loaded as ENV variables which is great. (Or possibility just one of them.)
This really should be a simple, out-of-the-box thing, but it's hard to find real documentation on best practices.
I've found the answer, at least the one I'm looking for. You can have your initializer load whatever file you want by overriding the defaults.
config.credentials.content_path = 'config/credentials/development.yml.enc'
config.credentials.key_path = 'config/credentials/development.key'
https://edgeapi.rubyonrails.org/classes/Rails/Application.html
I need to have a custom Logger that logs specific actions that occur in my deployed application in Heroku. This log is for the user to view (that's why the default logger is no good here).
While testing on development on local everything is fine. I have
logger = Logger.new(PATH)
logger.info("...")
PATH is set on environment variables.
Now I want to deploy to Heroku but I find myself with a problem: how can the user view this log? Where would I need to save it?
On heroku filesystem is read-only, you should log to stdout. Default log can be directed there by rails_12factor gem (or configure by youself, but the former is easier)
But for custom log, that is going to be viewed by the user it's better to write to db, because probability of future access control being needed is high
Heroku has an ephemeral filesystem meaning whatever file you upload would be deleted shortly afterwards.
If you need a custom logger on Heroku, I'd say you should probably use something that is more persistent. You may use something like Redis.
Look at this answer for more info.
I have some iPhone client tests that run against my development rails server. The whole suite runs an order of magnitude faster if I turn on class caching in the Rails config. On the other hand, that slows down development when I'm not actually running the tests.
I want the test suite to hit an action at the beginning to turn on class caching and another action at the end to turn class caching off again.
Is this even possible? If so, how?
Not without some serious hacking. Rails goes to quite a lot of trouble to make sure your files are reloaded on every request (when cache_classes=false). The value of the cache_classes configuration variable is used by initializers in several places not the least of which being:
using require to load ruby files when cache_classes is true (meaning they are no longer reloadable)
setting up dispatcher callbacks to reaload the application on every request when cache_classes is false
You do have access to the value of the cache_classes variable, and you can even change it if you like:
Rails.configuration.cache_classes = true
But, this will have no effect on the running rails instance as the initializers where that value is used only run once when the rails app starts up.
What this means is this, unless you're prepared to invest some serious time and hacking effort you can't really avoid a restart of your server. So, what you need to look at is controlling this restart process via your test suite.
For example you can try to restart rails from within rails. This would allow you to define an action that your test suite can hit right before it begins executing (to restart the server in the right mode), and another action which the server can hit after all tests have finished, to restart everything with cache_classes set to what it used to be. You would control the value of cache classes via an environment variable like this post suggests.
It would still require a bit of work to set all of this up and get it to hang together, but this is probably your best bet if you want an 'auto-magical' solution.
I don't think doing what you suggest will work.
But I suggest you may be looking for the wrong solution.
If what you want is to access your development database from your iphone testing,
then why not add a new environment.
Add a new file config/environments/iphone_dev.rb
require File.dirname(__FILE__)+"/development.rb"
config.cache_classes = true
And in your database.yml (or mongoid.yml or whatever)
iphone_dev:
host: localhost
database: my_app_development
There is no reason the database cant be the same
Now just run rails server -eiphone_dev -p3001
You should have a server, almost the same as your dev server,
but running on a different port, with caching enabled.
I can usually google around and find this kind of thing but I just can't find this one.
What I'm looking for is a list and description for all the variables that I can set in my deploy.rb file in a Rails 3 app with Capistrano 2.
I've found and read these:
https://github.com/leehambley/capistrano-handbook/blob/master/index.markdown
https://github.com/capistrano/capistrano/wiki/2.x-Significant-Configuration-Variables
http://theadmin.org/articles/2010/06/24/capistrano-variables/
But there are some other variables I'm aware of such as :scm_command, and :local_scm_command (found them here in SO) that are not listed there.
I also took a look at gems/capistrano/lib/capistrano/recipes/deploy.rb but the list is still incomplete.
Where is the complete list of capistrano variables?
Fun story, you can set whichever variables you want. The list of variables that actually need to be set and are used depends on the recipes you are using for deployment. When you're using your own custom recipes, you can set and use whatever variables you want. For instance, a particularly ugly part of my deploy config requires knowing which unicorn pid/config each app is using (as there are multiple unicorns handling utility things on this server in addition to the main app), so I have to
set :unicorn_pid, '/var/run/unicorn/rails.pid'
in one of the app config tasks.
Good luck!
I am working on an existing Rails 2.3.x application, So I was working on it and it was a messy code with great difficulty I was able to run the application. But now for every small change in one of my controller it is expecting me to restart my serer otherwise the changes are not reflecting back, Let's take an example scenario here, Let's just say in one of the before_filter method I just added a puts statement on top of the method and it was not printing in the log, after I restart the server it is printing, Can some one please let me know if I am missing something here.
What environment are you using?
The default environment is 'development', where the code is reloaded on each request. However, this behaviour can be overwritten in the config file.
To be sure that the code is reloaded, add this into your config/development.rb file:
# In the development environment your application's code is reloaded on
# every request. This slows down response time but is perfect for development
# since you don't have to restart the webserver when you make code changes.
config.cache_classes = false
If you are using config.threadsafe! It needs to be present before config.cache_classes=false as threadsafe makes cache_classes true again, following link would make it more clear. here
Maybe you have don't flush. The log system in Rails use a BufferedLogger. So need a flush to be print. Try a default logger.