I'm working with Ruby On Rails (v. 3.0.10) and using Compass (0.11.5).
I'm using two development environments:
The standard Rails' development environment, defined in config/environments/development.rb connected to a PostgreSQL database.
A copy of the development environment, dev-sqlite, defined in config/environments/dev-sqlite.rb, with the only difference being the attached database (this time a local SQLite when I'm on the run and I can't reach my development database server).
My issue with Compass is that when I'm running Rails in my dev-sqlite environment (using RAILS_ENV='dev-sqlite' before running any Rails command, Compass seems to work in production mode, and it does not regenerate my CSS files when I change the SCSS ones as it does when I'm in development environment. This makes my development work a lot harder...
I've tried to add this line to the config/compass.rb file and restart my local Rails server (with rails s), without success:
environment = :development if Rails.env == 'dev-sqlite'
In fact, even environment = :development doesn't change a thing.
Thanks in advance for the help!
I added the following to the bottom of my config file and it works well for me:
# Enable Debugging (Line Comments, FireSass)
# Invoke from command line: compass watch -e development --force
if environment == :development
output_style = :expanded
sass_options = {:debug_info => true}
end
Then you just need to specify that you are in development environment when you run compass watch (or compile). You can do this by running compass watch -e development --force. As you can see, I stuck that in a comment in my config file incase I forget.
Also, be sure to enable sass in chrome developer tools to take advantage of sass source maps
Related
I have set up a rails 4 server on Ubuntu 12.04 using Capistrano, Nginx, Passenger, Postgres, Redis/Resque
Everything is working great, except that the production.log file is always empty.
I have tried a variety of configuration changes in production.rb to no avail.
It's definitely not a permissions issue, as the permissions on both the log dir and each of the logs are wide open (777)
Can anyone hep me figure out how to get basic logging working?
The culprit was Heroku's rails_12factor gem
Removing that gem from the Gemfile, now the logs are working as expected.
# group :production do
# gem 'rails_12factor'
# end
To clarify, the rails_12factor gem was responsible, but that's only because it includes rails_stdout_logging, which is the real culprit, however, due to it's intended behavior to "ensure that your logs will be sent to standard out."
Check with the log levels in production.rb file, config.log_level = :debug will display it's errors. Also make sure the server is running production mode, in case you have not made any changes any configuration files for rails env, production mode is by default.
I’m currently deploying my Rails application on Amazon and I’m facing a problem with environment variables.
I'm using the dotenv gem on development and testing and it works just fine while trying to access my environment variables, but in production it does not seem to work. I read that the dotenv gem isn't meant to work on production. I have to set almost 20 different environment variables including API keys, etc., I'm deploying with rubber/capistrano.
How can I get this working in a clean way?
The dotenv-deployment readme mentions how you can use it in a production environment:
If you're using Capistrano 3+:
Just add .env to your list of linked_files:
set :linked_files, %w{.env}
If you're using Capistrano 2.x.x version:
In your config/deploy.rb file:
require "dotenv/capistrano"
It will symlink the .env located in /path/to/shared in the new release.
Remember to add :production group to the dotenv-rails gem in your application's Gemfile:
gem 'dotenv-rails', :groups => [:development, :test, :production]
You could use the figaro gem. I am using this and it works fine in production.
In Capistrano 3 add require "dotenv/rails-now" to your Capfile.
This will make sure that capistrano has access to the environment as well.
(We had issues with capistrano accessing the API token for appsignal, so capistrano wasn't able to notify appsignal when a new deploy was done)
I have deployed this app (rails 3.2.11) a million times, I haven't messed with any settings, but now I'm greeted with this:
Why did this happen out of the blue? My conents of application.rb include config.assets.enabled = true - never had any issues.
In fact running it locally on port 3000 seems to not have any issues whatsoever.
After deploying to heroku this morning, it seems that it loads nothing that's inside /assets/
Interestingly, after copying the files over to try and just make a new app, git commit results in all the stuff you'd expect as well as a LONG list of these which I think might be related:
Edit: Interestingly enough SOME of the assets have loaded, like the logo and the background, but the rest as you can see return 404.
put line in config/environments/production.rb
config.assets.compile = true
it worked as it will compile the assets on runtime, just like in development environment, but its makes application slow, the best way is to either compile the assets locally in production environment with rake task(RAILS_ENV=production bundle exec rake assets:precompile) and commit your generated assets in public/assets and then do deployment. or, heroku run rake assets:precompile
I had this problem today with rails 4 on heroku. The article provided by #Jeff is a little bit old but, the gem repository has a good readme.
Summarizing, you will need to add two gems to your Gemfile:
gem 'rails_serve_static_assets' (it will solve the static assets problem) and
gem 'rails_stdout_logging' (which the previous one depends on).
Heroku released a gem to handle the assets without needing to turn off compilation or to manually compile.
https://devcenter.heroku.com/articles/ruby-support#static-assets
Just add this to your Gemfile and redeploy.
gem 'rails_serve_static_assets', group: [:production]
For Rails 4, use:
config.serve_static_assets = true
The default was false. We needed this after removing the rails_12factor gem.
Rails recommended that this setting config.serve_static_assets by default should be disabled i.e. set to false. Here is the default configuration in config/environments/production.rb generated in rails app
Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = false
So if you are setting it to true in your local app then that's still fine. But if you are deploying your app on Apache or ngix or anything other than heroku then its not advisable to make config.serve_static_assets=true in your production.rb config file. Here is the documentation from Rails guides.
config.serve_static_files configures Rails itself to serve static
files. Defaults to true, but in the production environment is turned
off as the server software (e.g. NGINX or Apache) used to run the
application should serve static assets instead. Unlike the default
setting set this to true when running (absolutely not recommended!) or
testing your app in production mode using WEBrick. Otherwise you won't
be able use page caching and requests for files that exist regularly
under the public directory will anyway hit your Rails app.
URL - http://guides.rubyonrails.org/configuring.html
To make the assets to load with the corresponding fingerprint of each file verify the configuration config/environments/production.rb has the instruction:
ruby
# Load assets with fingerprint behavior
config.assets.digest = true
I've seen a few examples of dummy Rails apps (for testing, so they live under test or spec dirs, typically) for use with the Appraisals gem that supposedly work with both Rails 3.x and Rails 4, but they seem hackish and not fully functional. It is somewhat expected, as it is a stripped down Frankenstein monster that is trying to be compatible with various versions of Rails 3 as well as Rails 4.
I've referred to projects that attempt to do this sort of testing (as of late March 2013) like less-rails and ember-rails, but this way to test with various version of Rails doesn't seem very clean, and it is non-trivial to try to debug a non-standard Rails application, especially in a beta version of Rails.
It would be great to have a cleaner way to test that allows you to have a full Rails application for each version of Rails to test with that through some magic is not that difficult to setup or maintain and don't require non-standard path hacks in places, etc.
What are the available strategies for testing gems with various versions of Rails (including at least latest Rails 3.1.x, 3.2.x, and 4.0.0.beta1), and what are the pros and cons of each?
A few options from the related thread on the rails-core list:
Option 1: Appraisal gem and single Rails dummy app
Ken Collins mentioned using appraisal and a Rails "dummy" app:
I test minitest-spec-rails against 3.0, 3.1, 3,2 and 4.0 using a mix
of appraisal and dummy_app that minimally configures itself depending
which rails version it is testing against. Some links:
https://github.com/metaskills/minitest-spec-rails
https://github.com/metaskills/minitest-spec-rails/blob/master/test/dummy_app/init.rb
Similar techniques are used in less-rails, ember-rails, and high_voltage among others.
I used a similar setup to high_voltage in restful_json (v3.3.0) but with a full Rails app created with 4.0.0-beta1 that I modified minimally to also work with Rails 3.1.x/3.2.x.
Update: May want to see permitters for more recent example.
Pros: Fairly simple. Can test against various Rails versions from command-line, etc. Can be very minimal Rails app configuration, or can use full Rails app with minor differences.
Cons: Still reusing same Rails app for multiple Rails versions, so some conditionals and unneeded config. (Possible issues with some files not being applicable in another version of Rails, etc. but does not appear to be a big problem.)
Option 2: Rails version as environment variable with single Gemfile, single Rails dummy app, relying on travis-ci to test in multiple versions
Steve Klabnik mentioned a solution that works with a single Gemfile, a single full Rails app (even though under "dummy" dir, and no use of the appraisal gem, by relying on travis-ci to test:
I've been meaning to discuss this topic more, as I've been doing it
for a bunch of my gems lately. I have two that do this:
Draper: https://github.com/drapergem/draper
LocaleSetter: https://github.com/jcasimir/locale_setter/
Basically, I embed an entire Rails application into the gem, and then
run it against multiple versions of Rails on travis via env vars.
Pros: Simple. No dependency on appraisal gem (not that it is a problem, but may be easier to maintain).
Cons: Still reusing same Rails app for multiple Rails versions from what I can tell. Unless using travis-ci or something that starts with a clean gemset (i.e. if running at command-line), not currently differentiating gemsets so newer gem may be used with older Rails, etc., but Steve said if that were to cause a problem, you could just blow away the lock and re-bundle.
There's a third option : using multiple gemfiles and multiple dummy apps.
Gemfiles
Bundler has an useful option named --gemfile. With it, you can specify what file to use instead of Gemfile, and it will generate a lock file after the same name :
bundle install --gemfile Gemfile.rails3
bundle install --gemfile Gemfile.rails4
This will generate Gemfile.rails3.lock and Gemfile.rails4.lock. So, those Gemfiles can be a copy of your main Gemfile forcing rails version :
source "http://rubygems.org"
gemspec
gem "jquery-rails"
gem "rails", '~>4'
Using gemfiles from dummy apps
Then you have two dummy apps, one for rails-3 and one for rails-4. To use their proper gemfile while running (for example) migrations :
cd test/dummy_rails3
BUNDLE_GEMFILE=../../Gemfile.rails3 bundle exec rake db:migrate
cd ../dummy_rails4
BUNDLE_GEMFILE=../../Gemfile.rails4 bundle exec rake db:migrate
Yeah, that's probably the worst part. But this is mostly a one time setup.
Using gemfiles from rake
To instruct which version to use while running tests, set the environment variable BUNDLE_GEMFILE in Rakefile :
#!/usr/bin/env rake
rails_version = ENV[ 'RAILS_VERSION' ] || '4'
if rails_version == '3'
ENV[ 'BUNDLE_GEMFILE' ] = 'Gemfile.rails3'
else
ENV[ 'BUNDLE_GEMFILE' ] = 'Gemfile.rails4'
end
begin
require 'bundler/setup'
rescue LoadError
puts 'You must `gem install bundler` and `bundle install` to run rake tasks'
end
I prefer to ask the user to pass RAILS_VERSION instead of directly BUNDLE_GEMFILE because it's easier to remember and we can just pass "3" or "4".
Using correct dummy app from tests
Finally, in test_helper, switch the dummy app depending on what rails version has been asked for :
# Configure Rails Environment
ENV["RAILS_ENV"] = "test"
dummy_app = ENV[ 'RAILS_VERSION' ] == '3' ? 'dummy_rails3' : 'dummy_rails4'
require File.expand_path("../#{dummy_app}/config/environment.rb", __FILE__)
require "rails/test_help"
From your user perspective
For your user to run tests, he will have to do a one time setup by running the migration tasks with BUNDLE_GEMFILE, which is not that sexy.
But once done, user can run tests against rails-3 and rails-4 without the need to generate the Gemfile each time he wants to switch version, and you can have version specific code and configuration within your test apps without having to put if Rails.version >= '4' statements everywhere.
To run specs :
RAILS_VERSION=3 bundle exec rake test
bundle exec rake test # rails-4 is the default in code I wrote
You can see an example for this method in my activerecord_any_of gem.
I have an app that I run in three different environments, so sometimes when I pull it from github, I'll get the default rails "Oops, there was a problem with the server" page instead of the stack trace page. This seems to only happen when there's a problem related to a gem.
I remember maybe 6 months or a year ago when developing, if I had a missing gem, it'd show me the no such file to load -- mysql stack trace page.
This is mostly out of curiosity, but this actually does slow me down a bit as I have to tail the log to find what's broke on me.
You should add your gems in your environment.rb file.
For example if your application requires redcloth, you add in the environment file (the global one or any environment specific one).
config.gem 'RedCloth',
:lib => 'redcloth',
:version => '>= 4.2.2'
Your application won't load until you install that gem. And it'll display you a message asking you to install it.
You'll find more informations here.
Which server are you using to run your app?
Passenger runs in production mode unless explicitly told otherwise in the passenger configuration.
Any chance either of these lines appear uncommented in config/environemnt.rb?
ENV['RAILS_ENV'] ||= 'production'
ENV['RAILS_ENV'] = 'production'