Rails 3.2 assets:precompile - heroku

After wrestling with heroku for about a week and passing through various barriers to get it working (barriers to a newbie, I definitely don't fault heroku) I finally got my app running on it. One of the steps I had to adjust was precompiling my assets
bundle exec rake assets:precompile
and making some changes to the production environment in production.rb ...
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = true
Unfortunately this breaks a number of js behaviors on my local site. Works fine on heroku though. The way I've been handling this is to just rollback my local copy to a point just before these changes, but I'd like to understand why it's breaking. And also is there an assets:decomplile? Basically how the hell does one reverse the polarity or whatever? I'm definitely trying to get more intimate with the assets pipeline, but in the meantime any help or insight would be greatly apprecitaed.

To remove the precompiled assets in your local copy you just need to run
rake assets:clean
If you still have issues, clean your browser cache

Related

Debugging rails app in production when deployed with capistrano

I have deployed a rails application in a server using capistrano. What is the best way to debug this app in production?
Until now, when I used Apache+Phusion to deploy apps, I would write debug statements in the code and determine what was breaking.
But when I try the same now in the capistrano setup, I don't see the debug statements.
Where should I add the debug statements? In the code base that is pulled from the git repo? Or the current folder of capistrano?
Also, once I add the debug statement, is there anything I need to do to nginx server to reflect this change?
(Earlier, in Apache+Phusion, I used to do touch tmp/restart.txt to reflect the change)
Sorry for these questions, but this is my first time using Capistrano, Nginx.
I was deploying another agent's code, hence I wasn't fully aware of the deployment environment. On probing, I found out that the app server being used was Unicorn.
So, all I had to do to reflect the changes was restart Unicorn server by running unicorn appname restart

Asset_pipeline in heroku using the wrong asset hash for precompiled javascript

I'm trying to setup my app to serve assets over the Amazon S3/Cloudfront CDN. Its a rails app and I use the asset_sync gem to achieve this as per this heroku document.
I push my project up to heroku, and then afterwards run a heroku run rake assets:precompile. This gives me output that looks like this:
I, [2013-09-20T21:19:06.506796 #2] INFO -- : Writing /app/public/assets/application-cb6347d3ce9380e02c37364b541fd8ae.js
I, [2013-09-20T21:19:19.979570 #2] INFO -- : Writing /app/public/assets/application-9dc3068c1bf9290c7eb0493fd36b3587.css
[WARNING] fog: followed redirect to abc123.s3-us-west-1.amazonaws.com, connecting to the matching region will be more performant
[WARNING] fog: followed redirect to abc123.s3-us-west-1.amazonaws.com, connecting to the matching region will be more performant
Take note that the hash it writes for the JS file cb6347d3ce9380e02c37364b541fd8ae.js is correct (as I also ran this in staging under my localhost).
The problem though, is that when I hit my app on heroku and inspect the source, the JS that it is including 50460076f4c6eb614a44b6b17323efa7.js is different than the one that was compiled earlier...
Why isn't heroku picking up the right precompiled asset to use? I deployed locally and did all the same steps, my local server picks up the correct JS with no problem.
Thanks for your help!
After some time, I realized that this was because previously I had compiled assets locally and pushed it up. Because of this, Heroku didn't try to precompile in production and just used the old manifest.json that was previously checked in.
You can either recompile locally and push it up, or run rake assets:clobber to delete all precompiled assets, then commit/push and heroku will realize that it needs to precompile. Afterwards, it should be using the correct manifest file and assets should show as normal.
I found this blog post really useful in understanding the situation: http://www.rubycoloredglasses.com/2013/08/precompiling-rails4-assets-when-deploying-to-heroku/

Heroku with Play Framework AND Rake

I have a Play Framework app happily running on Heroku. I would like to run some rake tasks to backup the DB (OR, run anything for that matter to back up the db through a cron job on Heroku if there are other suggestions for java apps...).
So far i am striking out getting rake and Play Framework running together in the same app. As soon as I have a Gemfile there, Heroku things i am deploying a Ruby app and doesn't compile/deploy my play app. Appreciate any insights!
The Cron addon is no longer recommended on Heroku. The scheduler add on is recommended instead.
The way the documentation says to use the scheduler add on (if you are not building your apps in Rails) is to use Ruby by calling it from a script file in a bin directory. Check out the documentation here - https://devcenter.heroku.com/articles/scheduler

Slow asset pipeline/static files

I recently implemented Capistrano for the first time with a new cloud production environment. When I run cap deploy, everything seems to work fine. I can visit my live application in the browser, but my static files seem to load very slowly (like 5.0-12.0s).
See answer for clarity on config.assets.compile.
Static files load slowly because they possibly are not static, but are being served by Sprockets.
Check in production.rb and see if config.assets.compile = true or it is not set. That would mean that Sprockets is doing the work. You would also see far-future headers being used.
Have a look in /home/my_user/my_app/current/public and see if assets exists; I suspect it does not.
That means that mkdir -p is not working. The most likely cause is that the deploy user does not have sufficient permissions to create the directory.
Fix that, and also check (if this is an upgraded app from 3.0 or before) that your config setting match those in the last section of the pipeline guide.

Reduce Heroku Compiled Slug Size

I've just updated rails to v2.3.6 on my app under a bamboo-ree-1.8.7 stack and the compiled slug size has grown up to 40.5Mb! Previous to that last git push, the slug size was about 20Mb and was using rails v2.3.5.
Is it because my slug has both of rails versions installed? Probably I'm missing something but I haven't added any special code/files into my app as to increase the slug size by ~20Mb.
Can you point me on how can I reduce the slug size?
Any help will be greatly appreciated.
Thank you very much in advance.
One thing that helps is adding a .slugignore file to the root of your project to tell Heroku not to compile certain files or directories into the slug. Mine looks like this:
*.psd
*.pdf
test
spec
features
doc
public
The public entry is in there because I serve all static files from Amazon's S3 service; just leave that line off if you're not using an external content-delivery system.
If you're using less/bootstrap, on the cedar stack, then you can reduce slug size by precompiling and scripting up your precompile and push so that the less gem and dependencies are not included see here.
You can also exclude any gems that aren't used in production environment to trim things down a bit. Make sure your Gemfile splits gems according to environment and then exclude those environments that aren't needed.
heroku config:add BUNDLE_WITHOUT="development:test:staging"
Taken from a Heroku blog which is here

Resources