Handle missing credentials during `rake assets:precompile`

[turadg]

Heroku runs rake assets:precompile without the env config vars of the application. If you keep your MongoDB credentials in config vars instead of your source tree (as it best practice) then the credentials won't be available to Central Logger during this rake task.

That would be fine, because who needs the logger during assets:precompile, but currently it throws an error:

** Execute assets:precompile
CentralLogger Initializer Error: Unable to access log file. Please ensure that [...]/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Failed to connect to a master node at dbh00.mongolab.com:27007
[…]/gems/mongo-1.3.1/lib/mongo/connection.rb:518:in `connect'
[…]/gems/mongo-1.3.1/lib/mongo/connection.rb:656:in `setup'
[…]/gems/mongo-1.3.1/lib/mongo/connection.rb:101:in `initialize'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/mongo_logger.rb:146:in `new'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/mongo_logger.rb:146:in `connect'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/mongo_logger.rb:95:in `internal_initialize'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/mongo_logger.rb:22:in `initialize'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/initializer_mixin.rb:6:in `new'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/initializer_mixin.rb:6:in `create_logger'
[…]/bundler/gems/central_logger-d8e13e71b6ee/lib/central_logger/railtie.rb:11:in `block in <class:Railtie>'
[…]/gems/railties-3.1.0/lib/rails/initializable.rb:25:in `instance_exec'

The Rails 3.1 on Cedar docs say to handle this case in the initializer. What's the best way to accomplish this in CL?

I stopped CentralLogger:Filter in application.rb but it didn't help:

include CentralLogger::Filter if ! (Rails.env == 'test' or File.basename($0) == "rake")

Is there anyway to do this outside of hacking CL? If not, what's the best way to update CL to handle this use case?

[astupka]

I will update the railtie to deal with the rake scenario. Should be completed when I release an update for rails 3.1.3.

Alex