Heroku compatibility (WIP)

[wrs]

This is a work in progress to get Squash to work on Heroku.

You have to precompile assets in development because there is no environment set up when Heroku runs the precompile. This could theoretically be fixed by removing all of Squash's dependencies on environment settings, database connections, etc. in the precompile step. Meanwhile, set up a production database on the dev machine and do this (or equivalent) to deploy to Heroku:

git checkout -b deployment
RAILS_ENV=production rake assets:precompile
git add public/assets
git commit -m "Precompiled assets"
git push heroku deployment:master

The remaining problem is that about 3 out of 4 times the server process takes longer than 60 seconds to start up, so Heroku gives up (see Heroku docs). This timeout can't be adjusted. Either something is wrong, or that's just how long it takes to start up. In the latter case, there is a workaround where you start a proxy server to satisfy Heroku that forwards requests once the real server gets started.

[RISCfuture]

The latest version of JRuby includes the OpenSSL library by default. Including the gem only gets you a bunch of "Already initialized constant" warnings.

[nzifnab]

Hmm, pre-compiling assets doesn't appear to work for me in terms of making the app accessible in production. Everytime it tries to start the server it gets: /app/vendor/bundle/ruby/1.9.1/gems/squash_ruby-1.0.0/lib/squash/ruby.rb:21:in<top (required)>': undefined method find_by_name' for Gem::Specification:Class (NoMethodError) in the heroku logs.

Could this have to do with the version of RubyGems heroku has available on the Cedar stack? It appears significantly behind the one I have locally.

nbenes:squash(deploy)$ heroku run gem --version
Running `gem --version` attached to terminal... up, run.2339
1.3.7
nbenes:squash(deploy)$ gem --version
1.8.5

[RISCfuture]

IIRC, the find_by_name method has been removed in later versions of RubyGems. Note http://stackoverflow.com/questions/1032114/check-for-ruby-gem-availability and how there's a bunch of different answers to this question depending on the version of RubyGems.

[wrs]

Ah, right — you have to do rvm rubygems 1.5.2 (if you're using RVM). Need to put that in the README, I guess.

[nzifnab]

But that won't help on heroku will it? I think they have a set version of Rubygems. My local squash app ran flawlessly under RubyGems 1.8.5, it wasn't until I tried putting it on the old RubyGems that heroku is using that I get this error.

And I think @RISCfuture had it slightly backwards -- it appears the functionality was added in newer versions and the available?() method was deprecated and removed.

[wrs]

I was looking at the wrong thing. I have rubygems 1.8.24 on development, and heroku run gem --version shows 1.8.24 as well. I don't see any special setting I did to get that on Heroku. When you push to Heroku, do you see this?

-----> Ruby/Rails app detected
-----> Using Ruby version: ruby-1.9.3-jruby-1.7.2
-----> Installing JVM: openjdk7-latest
-----> Installing dependencies using Bundler version 1.3.0.pre.5

[wrs]

I just verified that a brand new app (heroku create -s cedar) has 1.3.7, but after pushing my branch to it for the first time, it has 1.8.24.

[nzifnab]

I wasn't using this branch to try to get it to work -- I added ruby '1.9.3' to the top of my Gemfile and that did the trick. They tie the version of RubyGems based on the version of ruby you're working with, the default must be an older ruby.

[nzifnab]

I don't believe you actually have to precompile the assets. I used heroku labs:enable user-env-compile and it seems to work successfully (this causes your environment to be loaded up when you deploy, allowing environment-specific things to be called during asset precompilation). Is jruby required? Things... appear to work using the thin web server and ruby 1.9.3, although as you can see in my other issue: #35 I still have one issue I'm trying to figure out.

[wrs]

Ah, I hadn't heard of user-env-compile.

Whether JRuby is required seems to be an open question.

[RISCfuture]

OK, so where do we stand on this? In my understanding...

• Heroku support is gated on finding a solution for the read-only filesystem issue
• There are other changes, not specific to Heroku, that would be good to pull in, but they've been moved out of this pull request (?)

Anything else?