The problem in a nutshell is that in development mode we'd make changes to CSS or JS files but would always get cached/old versions of these files. Nothing I did had any effect. I checked configuration dozens of times and tried every combination of config values but always kept getting the same results: stale/cached files. I had to actually run in production mode and restart the server after every change to test.
I spent days tearing my hair out over this issue, looked at dozens of stackoverflow questions on the asset pipeline but never found one that addressed it so I thought I'd post it here for posterity.
We use Heroku and precompile our assets because Heroku fails to precompile for us (we also use devise which apparently is the cause of the heroku precompilation failure). So in order to push our precompiled assets up to Heroku we have to check them in to git.
Here's the problem.
When we upgraded to Rails 3.1.1 asset precompilation produced files both with and without the MD5 hash in the name. I didn't think much of this and went ahead and checked all these files in so I could push to heroku. Sometime later I noticed the problem with cached results in development mode. The precompiled and checked in assets without the MD5 hashes were being served from /public/assets as static files which prevented us from seeing any changes we were making in /app/assets.
After finally realizing this I ran git rm /public/assets and everything works again. So the takeaway is: Be careful checking assets into git!
To turn this into a question: how do others do this? Am I missing something obvious? What I'd really like is for Heroku to precompile my assets for me but it is failing with a db connection error that I gather is because of devise. I had hoped Rails 3.1.1 fixed this but it didn't.
Have you checked out this devise issue on github? Specifically Jose Valim says
Rails 3.1.1 final has a method called
config.assets.initialize_on_precompile. If you set it to false, you
should be good but it won't allow you to access model information on
your assets (which you probably shouldn't anyway).
Maybe this will allow the precompile to happen on Heroku for you.
The reason the asset precompilation does not work could well be, that the Heroku ENV vars are not present on slug compilation (deploy) as stated here:
http://devcenter.heroku.com/articles/rails31_heroku_cedar
There is an (experimental) way to enable the ENV vars during deploy for exactly this reason, find information here:
http://devcenter.heroku.com/articles/labs-user-env-compile
Hope this helps.
Check this guide from Heroku. It outlines the 3 ways to deploy Rails 3.1 apps. Two of these do not required local precompilation.
Related
I've started learning rails and I've already built two apps, one simple blog app and one store app. Now I ran into a term precompile assets when uploading to heroku, can someone explain it to me is that necessary when deploying an app to production, because i've uploaded my store app to heroku without any problems?
Assets is your css + JS. Precompile assets mean that they get joined into single .css and another single .js. file (to load it in one HTTP request). And special mechanism of minifying get applied to both these files (to make them smaller). Rails by default is setup in a way, that it uses average files in dev and compiled files in prod. You can easily change this in configs, but you shouldn't do this unless you really know what you do.
If you want you can compile this files locally running rake assets:precompile and then put it into git. I think that you can disable/enable precompile during heroku deploy in heroku config. But, in general, I would stick with the very defaults.
More info on asset pipeline: http://guides.rubyonrails.org/asset_pipeline.html
Rails has an assets pipeline which consists of Sprockets and the assets helpers.
The assets pipeline will concat and minify your CSS and javascript and takes care of setting the correct paths to images and other assets. This is known as compiling the assets.
In development this is done on the fly for each request which lets you immediately see changes.
In production this would be far to slow so instead the assets should be compiled once at deploy time. Heroku does this automatically for you in a post-commit hook.
Pre-compiling is when you run rake assets:precompile locally and then upload or push the result to a server. This is done if you are deploying to a server without the support for the assets pipeline. For example if the production server does not have a javascript runtime which is required to run uglifier.
It adds tons of noise to the git change history and manually doing anything is a common source of user error. So pretty much it sucks and you only do it if you have to.
When I run assets:precompile on my server i can clearly see that my assets are getting precompiled, also files are being written to filesystem properly, but when I visit my application from browser I am getting not found error because asset file names that are being referenced in HTML are older ones.
I am absolutely clueless about how to debug this issue. Any kind of refrence/help will be highly appreciated
Based on OP's comments, the app is in production environment and as such, it needed to be restarted to force the app to reevaluate the asset hashes.
i have a Rails application deployed on Openshift. I added marker for hot deploing and hot deploying itself works fine, but during the time application is hot deployed css and js files are not served. When hot deployment ends these files work fine again. I also use Bootstrap and Sass in this application (gem 'bootstrap-sass'). Do you have any idea why this happens?
The files are being served by Apache via the Passenger module. The files are being replaced "in place" which causes them to be removed/rebuilt, which is causing them to not be served during that time, and since they are static assets, they are not stored in memory. Unfortunately there is currently no way to make hot deploy work fully with Rails to keep the site 100% working while it is deployed.
One solution is to have your assets in a separate running project, since there is no easy way to have them available as all times as #developercorey explains..
It's probably not the best solution, but would be a simple patch-solution which is not tightly coupled to one particular hosting platform.
I fixed this issue, and it works now. I will explain what I did, maybe it will help somebody.
Basically there is need to precompile your assets locally, and commit and push them. This is done byrake assets:precompile RAILS_ENV=production
But there is a gotcha!!! Locally precompiled assets doesn't match those that are generated on Openshift. How is this possible? There is a bug on Openshift, that assets are generated on production with RAILS_ENV=development :/ More info here:
https://github.com/openshift/origin-community-cartridges/issues/8
so there is need to add environmental variable on your application:
rhc set-env RAILS_ENV=production -a app_name
then generated assets match.
So after fixing it, when during changes to assets, we need to precompile them again. And to make them work during hot deploying there is need to have both old precompiled assets and new precompiled assets in repo. For example:
If you have old file:
application-10770925dc8abd4ceab34119af4032163cc5a94f3523d60d321f33a999171d58.cssand new precoimpiled file:
application-82f6fca47056cbda52cb32086051f031b880e2630a137f0e41e96cb2eef923ee.css
they both have to be in repository. During hot deploying old asset is still referenced, so it has to be in repository. After hot deploying ends, new asset is referenced. In the next commit and push old asset may be removed.
So basically this issue is fixed for me, and hot deploying works fine now.
I've seen various convoluted and generally ineffective solutions to performing lazy asset precompile in Rails. As a backend developer I don't particularly want to recompile assets I never touch every time the program deploys, but because assets are loaded in Capfile via load 'deploy/assets', and not by defining a task in deploy.rb, I can't think of a way to conditionally disable it.
The behaviour I'm after is to use cap deploy for regular with-precompile deployment, and to use cap deploy:no_assets to skip asset deployment.
Both turbo-sporocket-rails and the that auto-skip scripts have some pitfalls (I will mention later). So I use the following hack, so I can pass a parameter to skip asset pre-compile at my will:
callback = callbacks[:after].find{|c| c.source == "deploy:assets:precompile" }
callbacks[:after].delete(callback)
after 'deploy:update_code', 'deploy:assets:precompile' unless fetch(:skip_assets, false)
This script will change the built-in asset-precompile hook, so it will be hooked based on the skip_assets parameter. I can call cap deploy -S skip_assets=true to skip asset precompile as a whole.
For me, turbo-sporocket-rails still takes minutes to do the checking when nothing has changed. This can be crucial when I need to push a fix to the server asap. Therefore I need my force-skipping method.
rails4 addresses this issue with it's new version of sprockets, by only precompiling assets that have changed. In the mean time, for your rails3 apps I recommend the turbo-sprockets-rails3 gem.
This gem started out as a set of patches for sprockets-rails by Nathan Broadbent, which were not merged into master because the problem was already addressed in rails4. From the README:
Speeds up your Rails 3 rake assets:precompile by only recompiling changed assets, based on a hash of their source files
Only compiles once to generate both fingerprinted and non-fingerprinted assets
And:
turbo-sprockets-rails3 should work out of the box with the latest version of Capistrano.
I can confirm that it works well for me on rails-3.2.x apps deploying with Capistrano.
As a side note for GitHubbers, the original pull request is an excellent example of how to submit code to an open source project, even if it wasn't merged.
This gist looks very promising https://gist.github.com/3072362
It checks your git log from the last deploy to now to see if there are any changes in %w(app/assets lib/assets vendor/assets Gemfile.lock config/routes.rb) and if so, only precompiles then.
I'm just getting acquainted with Rails 3.1, and I burned some time updating an old project and trying to work out how the new asset pipeline behaves in development mode versus production.
The default config.assets.precompile setting blesses only application.css and application.js, with the intention that everything should be served as a single stylesheet and a single javascript file.
Obviously there are situations when we don't want that, so we can add items to the list in that config variable...
Here's the situation I ran into with my sandbox project when going to production:
Browsed the site in development, saw that everything was working. The assets were linked as separate files and the site displayed correctly.
Uploaded the site to my server, and tried to get it working in production. The first error was saying that "ie.css" (a conditional stylesheet) isn't precompiled. (I was in Safari and this stylesheet wouldn't even be downloaded: the error was raised from the stylesheet_link_tag helper before rendering the page.)
Ran rake assets:precompile and tried again.
Added the offending item to config.assets.precompile and tried again.
Kicked the error down the curb until it hit another asset error.
GOTO 3.
Not knowing how to address this, I went around in circles a few times until I thought I got all the assets and the site was rendering in production. Then I tried it in MSIE and hit another error 500: "belated_png_fix.js" was being conditionally loaded, and it didn't crop up until then.
So my question is, other than trial and error or a heavy dependence on integration testing, how can I predict that my site isn't going to bomb out when the asset pipeline discovers that some stylesheet or javascript wasn't added to the precompile list?
I'm also curious why a missing stylesheet asset should cause the whole page to error 500 instead of just compiling it on-demand or serving a 404 when that asset is requested. Is this a deliberate design to "fail early"?
I've just released a gem called assets_precompile_enforcer, which ensures that developers won't forget to add assets to config.assets.precompile while they are developing. An exception will be raised if you include an asset via javascript_include_tag or stylesheet_link_tag, and it doesn't match a filter in config.assets.precompile.
This means that asset errors will be caught during development, instead of being discovered after deploying to production.
I had similar problems with rails 3.1 as well. The best thing you could do is to install capistrano multi stage and get a staging server.
If for any reasons this is not possible, install a virtual machine on your computer and try to replicate your servers environment.
Continuous deployment is a great thing, and you should get to the point where it is so simple that it really isn't that painful anyway. That being said, config.assets.precompile can take regexs, so how about you come up with a standard for top level sprockets "manifest" files, or a standard sub folder for things that will not be bundled up? (note that I haven't actually tried this yet...)
This may be overkill, but this works for me (it gives me clean, compiled assets). I have this in my .bash_profile file.
alias ggo='bundle exec rake assets:clean && bundle exec rake assets:precompile && git add . && git commit -m "precompile" && git push origin master && cap deploy'
and this in my config/environments/production.rb (forces production to compile when needed; shouldn't be a need to if I remember to run "ggo" first):
config.assets.compile = true
So, my workflow is:
1. code
2. git add & git commit
3. if I touched CSS/SASS/JS/CoffeeScript files, I run ggo. Otherwise, I do a normal cap deploy.