I don't know it's just me, or everybody is facing same kinda issue. I am trying to precompile assets on server with this command -
bundle exec rake assets:precompile RAILS_ENV=production
but it takes about 10mins to compile all assets. The project is not big, its just started and has some 5 coffee script files, 3 css files.
Because of this, even capistrano deployments takes longer to complete.
Earlier it was ruby 1.9.2 there, now I am trying with REE 1.8.7.
Related
Using: rails4 app
Command: For Connecting and Rebooting in order to see the change.
rake assets:precompile
and
control + c
rails s
Is it normal!! Because, sometime I have to do a lot of change and I don't want to reboot the rails server 2000 times per hour.
It's development machine.
Suggestions would be appreciated.
I'm not sure why you're precompiling while still making changes to your SASS.
During development, if making frequent changes to SASS, I'll have cleaned my assets out and the server will pick up and compile these changes as I make them.
rake assets:precompile
is only used when I push to production
There is some guidance here: http://guides.rubyonrails.org/asset_pipeline.html#local-precompilation on why you might want to precompile locally, but I can't speak for your own projects.
I had a lot of headaches when trying to edit js files and refresh them while my assets were precompiled and they all went away went I ditched it in dev.
I solve it with this command
rake assets:clobber
Thanks anyway.
I used to develop a project on my own and now I have got some others to help in the project. It's developed with Ruby on Rails and we have a staging server on Heroku. Beforehand the deployment workflow is to precompile the assets in local machine then push the code to heroku. It works well when I am on my own.
Now I am working with a Front-end engineer. The problem is we are working in different location so it is difficult to setup his computer the same as mine. As a result, he will not be able to precompile the code before pushing to heroku.
Of course I can do it for him but would be better if he can just submit the code to the staging server and let Heroku to precompile it. I think Heroku detect if the manifest file is available to determine if it needs to precompile. Is there a way to force Heroku to recompile the assets?
I have tried: heroku run rake assets:clean then heroku run rake assets:precompile but no luck...
Heroku's servers use a read-only file system. This is how they make it easy for you to spin up more dynos, among other things.
Compiling Rails assets means taking the source files and compiling a new file, i.e. writing a file to the file system. Since this can't happen on a read-only file system, you have to precompile first. Even if you did manage to compile assets on Heroku, by writing to the /tmp directory, at the end of the day when Heroku reboots dynos, your new files will be gone because they weren't checked into the repo as they would've been if you had precompiled them locally, committed them, and then pushed to Heroku.
Any workaround I can imagine would be more complicated than helping your front end dev setup Rails and bundle installing the gems needed to precompile before pushing.
I am trying to deploy with capistrano version 3.
I have staging and production servers, after deploying to production, I manually do precompile in the server.
assets compilation takes a lot of time nearly more than half an hour, is there a way to reduce the precompile time, like not compiling unwanted/unchanged files
Turbo sprockets gem may be of some help.
It basically only compiles those files which have changed and not everything, if you don't want that you probably want to know which assets compilation is actually taking time by going through sprockets logs.
Recently I upgraded ruby version of my Heroku application after which it stopped compiling assets.
Initially I was using ruby version 1.9.2 and my assets were getting compiled while deploying the application. Recently I upgraded ruby version to 1.9.3 by specifying in gem file and adding config variable "RUBY_VERSION" for my application.
Everything is working fine now it is also picking right ruby version but it is not running assets precompile command while deploying application.
I have following line in application.rb
config.assets.enabled = true
A quick 'fix' for this would be precompiling the assets locally and then deploying the application.
I think its better, for a faster deployment.
First
rake assets:clean
then
RACK_ENV=production rake assets:precompile
When I run bundle exec rake assets:precompile --trace, my precompilation fails but I cannot see any specific reason for it.
See this pastebin for my output: http://pastebin.com/zggZyPyM
Precompiling assets takes a lot of memory. ~=400mb in my case. It might be possible that OS is killing of the process due to excessive memory usage. You can check the syslog to verify if that is the case.
You can increase the memory of your server to avoid the situation. If that is not possible, I would suggest that you precompile assets on your local system, commit them to the repo and deploy to the server. That way you wouldn't have to compile assets on your server. However you might want to look into ways to delete the previously generated assets somehow and also automate the process.
, but issue was resolvedI tried installing node.js first. And then, ran the following command bundle exec rake assets:precompile. Only then I didn't notice the error.
Initially, I thought it was because of low memory too. Cleaned almost all running applications, but couldn't find a solution. Plus, I opened Ruby as administrator. Not sure if that helped too, but issue was resolved.
This issue can also be resolved by using a node.js JS runtime to precompile assets as it apparently has a lower memory footprint. For Ubunutu 14.04 I needed to run apt-get install nodejs, then replace the default js runtime in the Gemfile with gem 'node', run bundleand finally rerun the precompile. I would caution against precompiling in another location as you may forget to do this after a css or js change, leading to errors.