Rails 3.1 Static Asset - Should Assets Be Precompiled for Productions?

My understanding of the new Rails 3.1 pipeline in production mode is as follows: →

  • config.action_controller.asset_host = "https://mybucket.s3.amazonaws.com"
  • config.assets.compile = false
  • app/assets checked on repo
  • bundle exec rake assets: precompile and synchronize with S3 (all assets)
  • public/assets NOT checked for repo

With all of the above, I thought that Rails would look for all the assets in S3, and I did not need them in the repository. Or at least I don't need pre-compiled assets in public/assets in the repo.

I found this on heroku, if it does not have config.assets.compile = true , it will not contain precompiled assets on S3. And heroku must go through the compilation stage for all assets, but then will call them from S3. Running heroku run rake assets:precompile does not crouch. The production process will compile everything again.

BUT? It makes no sense to me.

It would be wise for me that you do not need to fill repo with images, let your CDN work.

I feel like it's wrong. Am I right or wrong?

+7
source share
6 answers

If you have this kit:

config.assets.compile = false

no asset requests will be transferred to the Asterisks to be serviced. Files are expected to be precompiled.

Check out the Heroku Asset Pipeline setup guide , as there is a special setup to make it work.

+2
source

Definitely check asset_sync on github. Or our Heroku dev center article on Using the CDN Host Resource with Rails 3.1 on Heroku .

Problems with environment variables have recently been resolved by the Heroku labs plugin, which makes your heroku config applications variables available at compile time. To enable this, read the user_env_compile plugin. Tools that you no longer need to run heroku run rake assets:precompile after deploying the application.

Besides. There is a pretty big performance improvement when using asset_sync , allowing your application to lazily compile assets in production or serve them, pre-compiled directly from application servers. However, I would say so. I wrote this.

  • With assets_sync and S3, you can precompile assets, meaning that all assets are ready for immediate maintenance on the host / CDN of the asset.
  • You may only need a package : assets in the .rb application for precompilation, memory preservation during production
  • Application servers NEVER fall under asset requests. You know, you can spend expensive time computing. Computational.
  • Best practices HTTP cache headers are set by default.
  • You can enable gzip automatic compression with one additional configuration
+2
source

For reasons that I will never understand, I cannot mark the above answer as useful, but I had the same problem with my assets located on Amazon S3, and my application was deployed to Heroku.

Just checking "public / assets / manifest.yml" resolved the errors of the "asset not precompiled" when on Heroku.

+1
source

Setting 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 ... all of the JS / CSS assets were loaded into my development environment, but Production on Heroku lacked them.

Also see: Rails javascript is missing after precompilation

+1
source

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

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

https://github.com/rumblelabs/asset_sync

It will do everything for you, Heroku will precompile, and then the asset_sync gem will copy it to your s3 directory and url_helpers will work. I believe the disadvantage is that you need to start the pre-compilation phase (but it is only copied when the content changes), and you need to store your assets in your git repository.

0
source

I think what happens is that he searches manifest.yml to find out if the assets have been compiled. Since this file is publicly available / by default, and you do not check it for your repo, it assumes that the assets were not compiled. Try changing the location of the file in config/environments/production.rb and see if this fixes the problem

0
source

All Articles