Heroku Rails 3.1 App - Compiling Assets Locally VS Compiling Assets During Slug Compilation

Heroku rails 3.1 app - compiling assets locally vs compiling assets during slug compilation

I addressed some of these issues and a big gotcha in my question here: Rails 3.1.1 asset pipeline Heroku caching gotcha

I'd prefer #2 if it worked for me so I don't have to checkin compiled assets which just bloats the git repository.

Compiling assets during slug compilation won't result in any additional downtime because your existing app will stay up until slug compilation is complete so no worries there.

My advice would be #2 if you can make it work for you. If you do end up going w/ #1 then take best practice would be to git rm -r public/assets before rake assets:precompile to make sure no cruft remains.

Compiling Assets in Ruby does it need to be done in deployment? Why not before?

The solution was pretty simple

1) disable asset compiling during deployment

I'm using elastic beanstalk so just had to set this in the environment variables

2) Either

• Add the /public/assets folder to git
• Or for elastic beanstalk create .ebignore file and copy over the .gitignore but remove the /public/assets entry

3) before deploying run

• Linux -- RAILS_ENV=development bundle exec rake assets:precompile
• Windows -- set RAILS_ENV=development && bundle exec rake assets:precompile

4) deploy code to server as normal

• eb deploy

Heroku is not pre-compiling my assets to prepare my app for asset pipeline

Ok so the solution was this:

I'm using mongoid which has you remove the 'rails/all' line as part of the configuration. As a result sprockets was not being loaded.

What you need to do with rails 3.1+ is also add require "sprockets/railtie" in application.rb so that sprockets are enabled. Boom, works.

This info can be found on the mongoid website here. This is useful to know for anyone who may not be loading the full 'rails/all' in application.rb, sprockets is obviously required for the asset pipeline to work.

Why is my heroku app trying to connect to a database during asset compilation?

1. The task will likely have a dependency on :environment, which will load your whole application, including the startup code, where the database connection is established.

2. Asset precompilation serves the purpose to improve request time - rails doesn't have to compile the assets at every request. If you compile the assets locally, you are using your own machine, which most likely will be faster than the heroku env. You can easily use a hook to do the compilation automatically.

Assets pipeline when updating to Rails 3.1 on Heroku

I was wondering the same thing, but here's a tip to help figure out if your assets are live-compiling or not

1. run rake assets:precompile locally
2. make some changes to your css but do not rerun the rake task
3. git add, commit and push to heroku

If the changes you made in step 2 show up on heroku, then you know your app is live-compiling

Don't forget that you are now in charge of http caching since Varnish is no longer included on celadon, so you need to set up rack-cache and memcached yourself:

• heroku doc on http caching
• setup rack-cache with memcached on heroku
• heroku docs on memcached

But yeah, I found this puzzling too

Heroku precompilation of assets with no result

Have you tried deploying the app locally? If so you will get the same result.

When using the asset pipeline, it defaults to serving all CSS through application.css.

Are you able to change your stylesheet tag to:

<%= stylesheet_link_tag 'application' %>

If that displays correctly in development, then it should also work in production.

Alternatively, if you really need to include that file directly, then you will need to modify config/environments/production.rb to add:

config.assets.precompile += %w( blueprint/screen.css )

asset_sync Gem Causes Heroku to Hang on precompile

Turns out it was a problem in the Sass compiler. It was choking on something without throwing any kind of error. I managed to get a bit more information using the steps outlined here, by waiting until it was hung, then quitting the process. That gave me a stack trace back to the sass parser. Think it was some kind of circular dependency.

---

Related Topics