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.
Related
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 am developing with Rails 3.2.8.
One annoying thing is that if an image is missing by mistake, it gives an error in production mode.
Let's say that I put the following code.
And actually I forget to place my.jpg file in app/assets/images, it's ok in development (browser will just ignore the missing image) but it gives a rails error in production mode.
How can I find the missing files before deployment?
Thanks.
Sam
What I do when building a new release for a deploy is set the following in my config/environments/test.rb
config.assets.compile = false
config.assets.digest = true
This mimics the production environment config for the asset pipeline, preventing the assets from being compiled and forcing the lookups through the manifest.yml files/asset pipeline. Run your tests (you do have tests, right? :-) ) and watch for a failure.
If you don't have tests, grep you log/development.log for a 500 error
tail -f log/development.log | grep 500
Go through a few pages manually and watch for new log entries appearing in the tail. You should look into writing tests to automate this though.
The reason you're seeing the errors in production is because the asset pipeline can't find the assets you're requesting and raises exceptions due to this. In development things are more lenient so that debug info can be presented to you in favor of the 500 errors. By changing the above config in your environment, you're telling rails to act strictly with respect to it's response to missing assets through the asset pipeline, allowing you to catch the problem before it makes it's way to production.
You can watch the rails console running in dev mode... it shows a warning when it can't find the image.
Also, use the browser's error console. Both of those will tell you what's missing and then you just start grepping or visually searching to see where you did (or didn't) put the image.
I don't know why it would be annoying that the production server is less kind to the broken code than when you were in development unless you actually want to roll out code with missing objects and references.
So the question basically boild down to this:
How do you efficiently handle changing assets in a production rails environment without the need to restart the server?
The problem we're experiencing is, we have to restart the Thin server that runs the app in order for the updated javascript files to be served.
Some background:
Right now we're generating data from a couple of long running tasks into javascript files once an hour so we can use it in our Rails app.
To be clear, we update/overwrite existing files, not adding new ones.
After generation we run these commands in order to re-precompile all the assets.
bundle exec rake assets:precompile
bundle exec rake rails_group=assets assets:clean RAILS_ENV=production
Still after clearing the browser cache and reloading the page we're being served the old assets.
Have you guys made any similar experiences; what did you do to work around it?
PS. Happy holidays to you all!
So, what we ended up doing is basically letting rails also serve static assets by setting
config.serve_static_assets = true
in config/environments/production.rb
and just putting the frequently changing javascript data files into a directory structure under public/.
This works grate since it also separates assets and data into different locations.
According to the Rails guide:
6 How Caching Works Sprockets uses the default Rails cache store to
cache assets in development and production.
Rails is going to cache your assets unless you tell it to not cache them. The whole point of the asset pipeline is to serve assets as quickly as possible by encouraging browsers and servers and the rails servers themselves to cache the assets.
If your use case involves redoing assets very often, maybe the asset pipeline isn't for you.
I have a Rails app running on a shared web host under a folder in my root direction called 'mintrus-ror/'. There is a symbolic link 'public_html/' that points to 'mintrus-ror/public/'. My Rails app loads in the browser but the stylesheets don't load. Looking at the rendered source I noticed the assets path it is using is '/mintrus-ror/assets/application.css'. I am trying to figure out how to change it so it does not include the 'mintrus-ror/' directory in the assets path. Any ideas?
You can try playing with the config.assets.manifest configuration option in config/environments/production.rb. There are other variables that influence this, one being the web server configuration. I've got no recent (less than six years ago) experience with shared hosts, but I've read that on some systems, you can edit the .htaccess file.
I also presume that you're running in production mode and have previously compiled the assets with rake assets:precompile during your deployment step. Capistrano does this automatically when the asset pipeline integration is turned on.
The Rails Guide on the Asset Pipeline may be useful.
Your best bet may be to host on Heroku. It's free for small sites and a lot less hassle.
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.