ndbroadbent / turbo-sprockets-rails3

Speeds up your Rails 3 assets:precompile by only recompiling changed files, and only compiling once to generate all assets
MIT License
976 stars 78 forks source link

Still compiling all assets with Heroku #97

Closed nfriend21 closed 10 years ago

nfriend21 commented 10 years ago

Hi guys, I've added the gem but all the assets are still compiling on every deploy to heroku. Note: My asset files are hosted on Cloudfront, so not sure if that has something to do with it.

I should mention that it is working perfectly in development. I also cloned the application from heroku (via https://devcenter.heroku.com/articles/git-clone-heroku-app) and can see that there is no public/assets folder to even find the manifest.yml file.

ndbroadbent commented 10 years ago

Hi, you need to use the special heroku buildpack, which provides a shared assets folder between releases. See this section in the README: https://github.com/ndbroadbent/turbo-sprockets-rails3#heroku

nfriend21 commented 10 years ago

Hey Nathan - I actually had already done this before reporting my initial issue, and it still didn't fix anything. I ran this exactly, and there were no errors: heroku config:add BUILDPACK_URL=https://github.com/ndbroadbent/heroku-buildpack-turbo-sprockets.git

Also, I double checked my config vars to make sure it was there in heroku.

Any ideas?

ddgromit commented 9 years ago

I'm having the same problem, no errors but everything recompiles with every deploy even though it works locally.

My BUILDPACK_URL is set to the custom buildpack, and during slug compilation its calling rake assets:clean_expired as it should, so its executing the correct code in the buildpack. The only thing I can think of is it must not be storing the result in the cache.

Here's it running during slug compilation:

       Running: rake assets:clean_expired
       /tmp/build_d3ce9e7d-4118-4f0a-81b0-166723c8aa25/vendor/ruby-1.9.3/bin/ruby vendor/bundle/bin/rake assets:clean_expired:all RAILS_ENV=staging RAILS_GROUPS=assets

When I run it manually, it returns a successful exit code.

~ $ rake assets:clean_expired; echo $?
/app/vendor/ruby-1.9.3/bin/ruby /app/bin/rake assets:clean_expired:all RAILS_ENV=staging RAILS_GROUPS=assets
Connecting to database specified by DATABASE_URL
0

When running assets:precompile on an existing dyno, it sees the sources and works correctly.

➜  heroku run -r staging rake assets:precompile
Running `rake assets:precompile` attached to terminal... up, run.7754
Not compiling public-core.css, sources digest has not changed (7975d46)
...

It's only during slug compilation that its not loading the previous set of assets out of the cache.

Rails 3.2.19 with turbo-sprockets-rails3 0.3.14

nfriend21 commented 9 years ago

I'm still having the problem and can't find any solution to it. I did notice in the notes that he specifies that for our version of Rails, we should be using turbo-sprockets-rails3 0.2.x .

However, I've tried it, and it ends up needing older versions of various gems like railties and seemed to be a can of worms.

If you figure anything out, please let me know!

ddgromit commented 9 years ago

So this doesn't solve this issue, but I ended up just using memcache as the asset cache instead of the filesystem, and it works perfectly. The heroku addon "memcachier" has a free plan up to 25mb which was more than enough the fairly large asset collection I'm using.

config.assets.cache_store = :dalli, (ENV['MEMCACHIER_SERVERS'] || "").split(","), {
    username: ENV['MEMCACHIER_USERNAME'],
    password: ENV['MEMCACHIER_PASSWORD'],
    expires_in: 7.days
}