Posted by Luke Francl
on Thursday, February 18
Bundler may be the future, but after way too many hours of trying to get my app working with Rails 2.3.5, bundler 0.9.x, and Heroku I have decided to throw in the towel and switch back to Heroku’s gem manifest system.
I had Bundler 0.8 working very nicely but for whatever reason I couldn’t get the gems to play nice with each other in the new version. I had the app working locally and the tests passing, but on Heroku the app wouldn’t boot. This could have something to do with Heroku running Bundler 0.9.5 while I was running 0.9.7 locally. Whatever the reason, I’ve decided to take a break from bundler and wait until its development stabilizes a bit—at least on Heroku.
If you’re in the same boat, you can use this script to convert your Gemfile back to a .gems file and config.gem statements.
Posted by Luke Francl
on Friday, February 12
Deploying to Heroku is pretty easy, but I’ve often found myself needing to do additional tasks after pushing to Heroku’s git repository. For example, if you have to migrate, you have to do that after pushing; and after migrating you have to restart the app server.
So here is a Rake task to automate that. It uses Heroku’s client library to find the git remotes you need to push to. Use it like this:
rake deploy # deploys to your default app for this directory
rake deploy APP=some-other-app # deploy to another app (e.g., a staging server)
Posted by Luke Francl
on Sunday, January 31
Getting an error like this when you push to Heroku?
electricsheep:herokuapp look$ git push heroku master
Received disconnect from 75.101.163.44: 2: Too many authentication failures for git
fatal: The remote end hung up unexpectedly
If you like to create an ssh key for each server you use, you run this risk.
The reason is that unless you specify which key to use for a host, ssh-agent sends each key in turn until one works. However some server configure sshd to reject connections after too many attempted logins. For example, Dreamhost does this (see Dealing with SSH’s key spam problem for details). This is especially annoying if you weren’t even planning to use key-based authentication (as is the case on Heroku).
You can fix this by setting IdentitiesOnly yes in your ~/.ssh/config file. You can do this on a host-by-host basis.
host foobar.dreamhost.com
IdentitiesOnly yes
Heroku is a bit difficult to do this for because they don’t have a single IP address or domain (that I know of) you can configure this for.
As a workaround, clear your identities:
ssh-add -D
(Thanks to my friend McClain for his help with the ssh-add command.)