10

For Rails 3, this question and turbo-sprockets-rails3 look great.

For Rails 4, there seems to be some controversy over whether this has been fixed or not.

I'm currently using Rails 4 in production, and it seems that because Capistrano deploy:assets:update_asset_mtimes touches all assets, deploy:assets:precompile likewise re-compiles all of them. That recompilation is the single longest step in my cap deploy.

Ideally, this should be replaced by some checksum based manifest system, so that only those assets that have actually changed (or are dependent on ones that have changed) are re-compiled.

What is the best way to do this? (Assuming we're still doing it on the server, not the dev machine.)

Community
  • 1
  • 1
Sai
  • 6,919
  • 6
  • 42
  • 54

3 Answers3

2

Here is a great blog post from the guys at codeclimate about this. I've taken a look at it but not gone through the steps in production.

http://blog.codeclimate.com/blog/2013/10/02/high-speed-rails-deploys-with-git/

ezis
  • 311
  • 2
  • 10
  • That seems like a pretty radical change (well beyond the amount I was talking about). Definitely interesting though. – Sai Oct 05 '13 at 21:07
2

This guy got it right for Capistrano 3. Works well for me. https://coderwall.com/p/aridag

bymannan
  • 1,353
  • 2
  • 13
  • 23
1

This issue was discussed in https://github.com/capistrano/capistrano/issues/478 and the solution which seems to be okay is simply to deactivate the touching. In above issue there was talk about a configuration variable to use for this but i could not find any code references to it. Instead we now simply overwrite the task.

namespace :deploy do
  namespace :assets do
    task :update_asset_mtimes, :roles => lambda { assets_role }, :except => { :no_release => true } do
    end
  end
end

Note: This is only true for capistrano version 2. I have no idea if version 3 still uses the same tasks or not.

Michael
  • 136
  • 4