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.
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.
Let me start by saying I am using Ruby 2.0.0 and Rails 4.1.1
I've worked my way through the Treehouse basic RoR course; ending in a very basic version of Twitter. I have the application running just fine on my local install, but when I pushed it to Heroku it seems to be missing the files in the /public directory; namely the /assets css and javascript.
I've precompiled my assets as instructed, and verified that they area indeed showing up on my GitHub remote that is using the same branch. I was told that Heroku will not compile your assets for you.
All my routes and HTML is displaying just fine, but I cannot pull any of the files that live in the /public directory (404.html, 500.html, etc)
It feels to me like it is a permissions issue or something with the /public directory, but I haven't found a way to actually browse what files are on my Heroku instance. I've tried re-pushing several times while making small changes, and the css/js never seems to appear.
In case that you have already set:
config.serve_static_assets = true
in your config/environments/production.rb
And still not working, you can actually see the logs from your heroku app using heroku logs or heroku logs -n NUMBER_OF_DESIRED_LINES_HERE in your terminal.
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.
I have the option to precompile my assets locally in development or on my production server. I deploy with git, so I'd prefer not to have to check in all these assets (especially if they're using cache-busting digests).
Is there any advantage to precompiling assets locally (other than lacking write-access on the production machine)?
Your site doesn't need to be down when you precompile assets. If you use capistrano or similar tools, you precompile the assets in the server, then (after this and more steps have been completed) restart the app. Meanwhile the app is being served from the old code (and assets).
On the other side, I disagree about the "cache-busting" comment. Git is smart enough to understand a diff between two differently named files if possible. So the result would be exactly the same whether the names changed or not. In which case I completely agree that it's nonsensical to load the repository with generated data, like compiled assets.
I've found that compiling assets locally is much faster and then your site is down for a shorter period.
Of course, that depends on your server setup etc...
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.