Ruby Language Pack
The Ruby Language Pack requires a
Gemfile.lock file to be recognized as a ruby app. It will then proceed to run
bundle install after setting up the appropriate environment for ruby and bundler.
Gemfile.lock files, the
--deployment flag will be used. The
vendor/bundle directory is cached between builds to allow for faster
bundle install times.
bundle clean is used to ensure no stale gems are stored between builds.
To enable static assets being served on the dyno, rails3_serve_static_assets is installed by default. If the execjs gem is detected then node will be vendored. The
assets:precompile rake task will get run if no
public/manifest.yml is detected. See this article on how rails 3.1 works on cedar.
Auto Injecting Plugins
Any vendored plugin can be stopped from being installed by creating the directory it's installed to in the slug. For instance, to prevent rails_log_stdout plugin from being injected, add
vendor/plugins/rails_log_stdout/.gitkeep to your git repo.
Ruby Language Pack Flow
Here's the basic flow of how the language pack works:
Ruby (Gemfile and Gemfile.lock is detected)
- runs bundler
- installs binaries
- installs node if the gem execjs is detected
rake assets:precompileif the rake task is detected
Rack (config.ru is detected)
- everything from Ruby
- sets RACK_ENV=production
Rails 2 (config/environment.rb is detected)
- everything from Rack
- sets RAILS_ENV=production
- install rails 2 plugins
Rails 3 (config/application.rb is detected)
- everything from Rails 2
- install rails 3 plugins
Add this language pack to your
heroku config:add LANGUAGE_PACK_URL="http://github.com/heroku/language-pack-ruby.git"
Rakefile consists of tools used to help with vendoring libraries. You'll need the vulcan gem to build binaries on heroku. We also use Amazon's S3 to store all of our vendored libraries. The rake tasks create tarballs which are referenced by the language pack and unpacked during slug compilation.