Here’s yet another take on how to handle generated files when you are deploying to Heroku while keeping your git repo free of the artifacts.

We deploy using a rake task rake deploy that was generating Jammit files, committing them to the repo and pushing them up. This works fine, but adds “junk” commits to your repo and even the occasional merge conflict from the generated files.

Since Heroku doesn’t care what you push to it as long as it is in the master branch on their end, why not generate the assets in a throwaway branch and push that up?

Here are the basic commands you would run in the shell. Wrap them up in a rake task that fits your project and off you go.

# send it up to github
git push origin master 

# get rid of the branch if it exists (it shouldn't)
git branch -D deploy

# generate Jammit, Sass, etc. files
rake cache_assets 

# push it up to heroku, need force since it's a different branch every time
git push heroku deploy:master --force 

git checkout master

# get rid of the old branch
git branch -D deploy 

As long as everybody uses the rake task to deploy you shouldn’t have any problems with this technique.

We are using websolr.com from one of our Heroku apps and from time to time we see connection errors. This is disruptive in the UI. One option was to move all of the Solr calls to DJ tasks, but I didn’t want to have a ton of stuff in the DJ queue. The other option was to make a variation of SilentFailSessionProxy and have it queue up the jobs we cared about, specifically index and remove and raise the others.

Here is the current version of this.

require 'sunspot/session_proxy/silent_fail_session_proxy'

module Sunspot
  module SessionProxy
    class QueueFailureSessionProxy < Sunspot::SessionProxy::SilentFailSessionProxy
      QUEUE_METHODS = [:index!, :index, :remove!, :remove]

      def rescued_exception(method_name, ex, klass)
        raise ex unless ::Rails.env.production?

        if klass && QUEUE_METHODS.include?(method_name)
          HoptoadNotifier.notify(
            :error_class => "Solr Exception",
            :error_message => "Solr Exception: #{ex.message}",
            :parameters => { :model => klass, :method => method_name }
          ) if defined?(HoptoadNotifier)

          klass.delay.index! if method_name.to_s.match('index')
          klass.delay.remove_from_index! if method_name.to_s.match('remove')
        else
          raise ex
        end
      end

      SUPPORTED_METHODS.each do |method|
        module_eval(<<-RUBY)
          def #{method}(*args, &block)
            begin
              search_session.#{method}(*args, &block)
            rescue => ex
              self.rescued_exception(:#{method}, ex, args.first)
            end
          end
        RUBY
      end

    end
  end
end

Sunspot.session = Sunspot::SessionProxy::QueueFailureSessionProxy.new(Sunspot.session)

Scenario: I have to setup a staging app on Heroku. Sounds pretty simple, should take an hour tops, right? Think again.

Mix in a gem from a private git repo and it gets messy. If the gem isn’t installed via version but with a commit ref you get even more fun.

Setup the app on Heroku as you normally would, then try to deploy. Everything looks good, until it tries to fetch the private gem. Then

git push heroku staging:master
-----> Heroku receiving push
-----> Rails app detected
-----> Detected Rails is not set to serve static_assets
       Installing rails3_serve_static_assets... done
-----> Gemfile detected, running Bundler version 1.0.3
       Unresolved dependencies detected; Installing...
...

<tries to install private gem>

Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Hrm… Poke around the google some and find I’m not the only one. See references to an ~/.ssh/config that looks something like

Host heroku.com
  HostName heroku.com
  User git
  ForwardAgent yes
  IdentitiesOnly yes

Sounds reasonable. Nope, no luck. More time with google and it would seem that Heroku doesn’t pass your keys out the other side. Not sure if they have a specific reason for it or it’s just the default sshd_config.

Ok, that’s not going to work. Lets try dropping the gem in vendor/cache and see if that helps. Oh, there isn’t an actual gem to cache. Lets grab the one in bundler. Nope that wont work either.

Off to build the gem so I can place it in vendor/cache.

cd ../my_gem
rake build
cp pkg/my_gem-0.0.2.gem ../rails_app/vendor/cache
cd ../rails_app
bundle install

WTF!? Oh, it saw one gem in the cache dir, I must want them all in there, right?? No, no I don’t.

Ok, well let’s place the gem in the app in a place I can get to it with bundler but it wont randomly trigger some other unwanted behavior.

gem install ../my_gem/pkg/my_gem-0.0.2.gem
gem unpack my_gem -v 0.0.2 --target vendor/private_gems

Ok now I update my Gemfile to look like

gem 'my_gem',
  :path => 'vendor/private_gems/my_gem-0.0.2'

So far it seems happy.

Though I have seen some really strange issues with it randomly Throwing the Gemfile.lock - Heroku has a read-only filesystem error which would make perfect sense other than the fact that the error came from running heroku rake db:migrate right after a successful push.

If you are reading this the site has moved to Heroku and is now powered by JABE in addition to the info on github, more info on JABE coming soon here.

I finally decided to start using Passenger and the stock Apache in OS X Snow Leopard.

Here are the steps I followed, from memory, so if they are missing anything please let me know.

install PassengerPane

rvm install ree
rvm ree
rvm gemset create APP_NAME
gem install passenger
rvmsudo passenger-install-apache2-module

Add an .rvmrc file

rvm --rvmrc --create ree@APP_NAME

Find the gems info

rvm ree@APP_NAME
rvm info | grep GEM
  GEM_HOME:     "/Users/mmoen/.rvm/gems/ree-1.8.7-2010.02@APP_NAME"
  GEM_PATH:     "/Users/mmoen/.rvm/gems/ree-1.8.7-2010.02@APP_NAME:/Users/mmoen/.rvm/gems/ree-1.8.7-2010.02@global"

add those to the /etc/apache2/passenger_pane_vhosts/APP_NAME.local.conf

SetEnv GEM_HOME /Users/mmoen/.rvm/gems/ree-1.8.7-2010.02@showcase
SetEnv GEM_PATH /Users/mmoen/.rvm/gems/ree-1.8.7-2010.02@showcase:/Users/mmoen/.rvm/gems/ree-1.8.7-2010.02@global

Make sure the envs are setup in /etc/apache2/passenger_pane_vhosts/APP_NAME.local.conf

RailsEnv development
RackEnv development

If you make changes to routing or other places that don’t autoload, you will need to restart the instance

touch tmp/restart.txt

Known issues:

If you are running a Rails 2.x app this way you will have to delete config.ru before starting or restarting the app. Otherwise it messes up Rails.env.

And as always, feel free to tell me I’m way off or if you have any input, please share it.

[edit] Update .rvmrc creation per Wayne’s suggestion

If you are a Textmate user and you were tired of Find in Project being a dog, so you started using Grep in Project and even it was getting slow. You absolutely owe it to yourself to check out Ack in Project. It is ridiculously fast.

I forked and modified the Cucumber and RSpec TextMate bundles to setup the rvm environment based on an .rvmrc in your project directory.

Cucumber Bundle

RSpec Bundle

Enjoy. Let me know if you find any quirks.

Ok so in my last post I mentioned I wasn’t able to find a way to automatically use an existing .rvmrc file. I spent some time with it again this afternoon and was able to get it to work. So now if you are using TextMate and you want to run a ruby script that uses your rvm environment all you have to do is edit the commands you use and replace the #! and add a couple lines. The odd thing is this is pretty much exactly what I was trying before, though on a different machine.

#!/usr/bin/env bash

[[ -f "$HOME/.rvm/scripts/rvm" ]] && . $HOME/.rvm/scripts/rvm
[[ -f "$TM_PROJECT_DIRECTORY/.rvmrc" ]] && . $TM_PROJECT_DIRECTORY/.rvmrc

And that’s it, you get your rvm config in TextMate.

So I started playing with rvm a while back and loved the concept of being able to have a gems(et) for each project to completely eliminate gem clashing.

So I now have an .rvmrc in each project directory with the necessary gems installed, no more, no less.

I also have a global gem set that has common gems in it that I use all over the place and aren’t really project specific so I don’t have to install them in every gems(et). Thanks Wayne!

Now, to take it to the next level I wanted to be able to use ⌘^R to run the current Cucumber scenario. So I needed to get TextMate aware of my rvm gems(et). This requires setting 3 project specific variables in TextMate.

1. TM_RUBY
2. GEM_HOME
3. GEM_PATH

To get TM_RUBY cd into your project with a .rvmrc in it or set the environment with rvm your_ruby%gemset then run

which ruby

To get GEM_HOME and GEM_PATH run

env | grep GEM

To set these in your project you need to have the project drawer open and nothing selected, then click the “I” button in the bottom corner, then you can add your variables.

I tried to think up a way to have TextMate read the .rvmrc in the project directory, but I wasn’t able to get anything to setup the environment. If anybody has any suggestions I’d love to hear them.