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
Related
I'd like to get the release version of my app in Heroku on PHP. I was hoping it might be available as an environment variable, for example like $_ENV['HEROKU_RELEASE'] might retrieve v23. Is there a way to get ahold of this?
Yes, that is possible, by enabling dyno metadata on your app with the following command:
heroku labs:enable runtime-dyno-metadata -a
Then, Heroku will set a HEROKU_RELEASE_VERSION environment variable on your app (as well as other ones, which are all described in the article linked above).
That variable includes the number of the current release for your app.
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/
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
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.
I'm running a few rails/rake apps in Apache/passenger and I want to add the documentation app served by gem server to these apps, so I can easily give it a special (sub)domain, like docs.example.org, so it's easily available for all members of our team and nobody has to start the server himself or remember port numbers (like 8808, the default gem server port).
I would recommend looking into bdoc instead of gem server, it allows the user to access all their gem docs without a server running at all. It would also be trivial to modify bdoc to output to a specific directory then you could easily add a step to regenerate the docs.
The nice thing about having them in static files would be the apache config is dead simple.
If you do want to make bdoc output to a specific dir look at this line.
Edit:
I actually went ahead and branched this on github and made the change. Now you can supply the output directory on the command line and it will generate the static rdoc pages for you.
I'm running http://gems.local on my machine in case I want to do some Ruby cracking offline. (Plain journey, trains, etc).
This is really easy, you can actually run passenger with all the Ruby gems' documentation locally without having to access the net.
I was following Jason's tips and got everything working. See the following article and you should be ready to go:
http://jasonseifer.com/2009/02/22/offline-gem-server-rdocs
Attila
I wrote a blog post on how I have my gems, ruby, rails and jquery docs locally using the yard server and nginx for proxing in mac os x. Steps for linux are almost the same, only thing that changes is the way to configure the daemons.
https://makarius.posterous.com/offline-rails-ruby-jquery-and-gems-docs-with