Hacker News Reader

Comment by simon_vetter | Hacker News Reader

If the reason you're using github is its tools and (nice) interface, why not start your deploy by syncing github to your private repo, then have capistrano always pull from there? Less code paths to test and no need to define env[FALLBACK]. Also, it's probably faster.

View on HN

A simpler way is just define two remotes to push and pull from in a single namespace say origin. If one is up you'll have no real problem. No need for code paths to test or having fallback stuff either. Just make git use both remotes. Linus uses git that way.

http://marc.info/?l=git&m=116231242118202&w=2

Nice, I didn't know one could have multiple urls for the same remote.

This post does not specify what happen on a `git fetch all`. I suppose it takes the first one, and you have to specify other remote entries if you want to pinpoint the remote repos to use ?

Note that the deploy I mention will do a fetch, so this solution does not replace the fallback variable.

No idea on git fetch all, but for a normal fetch it just iterates if the first one say fails it goes to number 2 in the list etc..

Past that I've not used it that often outside of having a cheap cluster solution in a way. Try it out and let me know!

The fallback repos is used as often as its name suggest :)

We do not use github only for issues and PRs, though, but also with repos hooks : pushing to a branch trigger a build on our CI, which then deploy our staging env if successful.

Of course, we could do as well with git hooks and writing code to do the web push. I just can't see any reason to migrate to that.

Today when I deployed a dependancy from NPM was unavailable due to Github being spotty, and somehow the deploy process let the app start without all dependancies, causing it to 502 everywhere.

I guess I'll have to look into what ElasticBeanstalk is doing.

Reply on news.ycombinator.com