Rails 3.1 Static Asset - Must Assets by Precompiled for Productions?

Question

My understanding of new Rails 3.1 asset pipeline in production mode is as follows:->

1. config.action_controller.asset_host = "https://mybucket.s3.amazonaws.com"
2. config.assets.compile = false
3. app/assets are checked into repo
4. bundle exec rake assets:precompile and sync with S3 (all assets)
5. public/assets is NOT checked into repo

With all the above, I thought Rails would look for all the assets on S3 and I don't need them in the repository. Or at least I don't need the precompiled assets in public/assets in the repo.

I have found this, on heroku, if don't have config.assets.compile = true, it flat out will not find the precompiled assets on S3. And heroku must run through a compiling phase for all assets, but then will server them out of S3. Running heroku run rake assets:precompile doesn't do squat. The production process will re-compile everything again.

Huh? That makes no sense to me.

I would make sense to me that you do not need to fill your repo with images, let your CDN do the work.

I have a feeling this is incorrect. Am I right or wrong?

Answer 1

When you have this set:

config.assets.compile = false

no requests for assets will be passed to Sprockets to be served. It is expected that the files will be precompiled somewhere.

Check out the asset pipeline setup guide on the Heroku site as there is a special setup to get it working.

Answer 2

Definitely check out asset_sync on github. Or our Heroku dev centre article on Using a CDN asset Host with Rails 3.1 on Heroku.

The issues with environment variables have recently been solved by a Heroku labs plugin, that makes your application's heroku config variables accessible during compilation time. To enable this, read about the user_env_compile plugin. The means you no longer have to run heroku run rake assets:precompile after deploy of an app.

Also. There is quite a big performance improvement in using asset_sync vs letting your application lazily compile assets in production or serving them precompiled directly off your app servers. However I would say that. I wrote it.

• With asset_sync and S3 you can precompile assets meaning all the assets are there ready to be served on the asset host / CDN immediately
• You can only require the :assets bundle in application.rb on precompile, saving memory in production
• Your app servers are NEVER hit for asset requests. You can spend expensive compute time on, you know. Computing.
• Best practice HTTP cache headers are all set by default
• You can enable automatic gzip compression with one extra config

Answer 3

For reasons I'll never understand, I can't mark the above answer as useful - but I had the same problem with my assets being on Amazon S3 and my app deploying to Heroku.

Simply checking in "public/assets/manifest.yml" solved the errors of "asset not precompiled" when on Heroku.

Answer 4

Adjusting my production.rb file to include 1) config.assets.precompile += %w( *.js *.css ) 2) config.serve_static_assets = true and 3) config.assets.compile = true did the trick for me.

Before including these... my Development environment had all the JS / CSS assets loading, but Production on Heroku was missing them.

Also see: Rails javascript asset missing after precompile

Answer 5

Let me give you a big hint, do it the official Heroku way:

http://devcenter.heroku.com/articles/cdn-asset-host-rails31

https://github.com/rumblelabs/asset_sync

It will do it all for you, Heroku will precompile and then the asset_sync gem will copy it to your s3 directory and the url_helpers will just work. I suppose the downside is you have to run the precompile phase (but it only copies when stuff changes) and you do have to store your assets in your git repo.

Answer 6

I think what's happening is that it's looking for the manifest.yml to know if assets have been compiled. Since this file is in public/assets by default and you're not checking that into your repo, it's assuming that the assets have not been compiled. Try changing the location of the file in config/environments/production.rb and see if that fixes the problem