Question

Here’s what I’d like to do in concept:

“Hook” node.js to a particular Git repository so that I can make a request like /84de7e8d8ce33/foo and the server will (if necessary) check out commit 84de7e8d8ce33, start up another node.js on the files it just checked out, and pass “/foo” to that new server. Of course, the main server keeps track of which commits it already knows about.

Basically, I’m just trying to simplify our release process, so the same server that does the above Git magic will also serve an index.html-like file that consists almost entirely of

<script src="/84de7e8d8ce33/app.js"></script>

My questions:

1. Just how bad an idea is this?
2. Is there some prior art, some library or framework that already does this?
3. Is there an alternative? Some way that I have a release branch, tell node.js what commit to use, and let it go.
4. Is there some built-in way of keeping multiple commits “checked out” (or at least visible as ordinary files in some fashion) at the same time?

(I have a subsidiary question about how to communicate, from me, as the release manager, to the server the fact that 84de7e8d8ce33 is now the live version. Right now, I’m thinking, memcached, but I’m open to other suggestions.)

Answer 1

It doesn’t sound like a bad idea at all. I would first try using https://github.com/libgit2/node-gitteh

Besides having a cute name, it

• should be faster than shelling out to git
• has a javascripty API

I would run it in a separate process from the web server, using node-redis and/or dnode to communicate.

Edit: I found the docs, listed at the bottom of the README. Not until after I looked at an example and played with it in the node repl, though! It’s quite nice. I was able to poke around and get a blob out of my repo. Also it works on .git, not a working tree, so you might be able to have multiple possible commits without having multiple copies of the repo.