Ryan Carmelo Briones

mostly harmless

Push-to-Publish Website with git and Jekyll July 27, 2009

I’ve been jealous of Github Pages for quite sometime. It’s an awesome idea. If you don’t know, it goes something like this:

  1. Edit your content using your favorite text editor and brand of markup. Personally I prefer Markdown.
  2. git push your content to a specially named repository on Github.
  3. Profit!

Seriously, it’s that easy. I’ve tried it. Most of this is managed by a project started by Github Co-Founder Tom Preston-Werner called Jekyll. Jekyll, “a blog-aware, static site generator in Ruby” is software developer for, “it takes your marked up content, applies a layout and generates static pages for your website blog.”

SO awesome, this blog post should be finished right!? Well, not quite.

thinking hard on whether i should reinvent the wheel or not

Incorporate into my current site

I’ve decided to put a lot of work into creating a “personal branding” website that I want to incorporate my blog into. I tried a little Apache ProxyPass-fu, not before turning my web server into an open proxy for ~15 days (!!!), but besides the fact that I didn’t have immediate results getting the resulting hyperlinks to come out proper, it just didn’t feel right.

Jekyll is open source; Github Pages is not.

When I had first tried to work with Jekyll I had forked it and made some customizations. In the future, if I make customizations to Jekyll that I really want and count on, I have no guarantees if/when they will be available to Github Pages.

Social Integrations

Eventually, I want to incorporate my more social proclivities into my website: Twitter, Github public commits and Gists. Before you start screaming, I know there are ways to achieve this with Javascript, I just don’t want to use it, not to mention that any HTTP connection twitter.com is blocked by the proxy server at the place I work at 40 hours a week. The Github scenario doesn’t really fit in with the fetching/storing-as-static model either.

Control Freak

I’ve been doing web development and system administration going on a decade. (Holy crap!) I feel like I have a good idea when to keep things close, and when to rely on someone else. Heck, I pay for a “Small” Github account and I have no problem putting all my verison control there. In fact, I love it. But my website hosting, not so much. No offense guys.

Imitation is the Highest Form of Flattery?

So I’m thinking, and I’m thinking. First thing that goes past my mind: “It’s too hard to set up a git repo on the server, right?” Yeah, no more of that gitosis mess. (“Too many hits with the snake!”) More “thinking.” Sintra app with page caching markdown converter? Too much reinventing. I even considered embedding a Ruby-based git-server implementation straight into a blog app for “easy setup”. Right… WAY too much reinventing.

I’m missing something… right?

How exactly does one setup an authenticated remote git server? My experience with github and gitosis leads me to believe that SSH has something to do with it since they both require my SSH public key. I log into my server using my SSH public key…

After a little Google searching what did I find out? I was wrong. It happens. Setting up a remote git repo is easy. Now, my publishing a blog post or editing a page on my website is as simple as git push publish master. This happens by the powers of git’s post-receive hook in cohorts Jekyll. Here’s how I did it:

  1. I already had my site being served by Apache. It was being served out of my home directory. ~/sites/USERNAME/public.
  2. I created a “bare git repo” for pushing to

    1. cd ~/sites/USERNAME
    2. mkdir source.git source
    3. cd source.git
    4. git init --bare
    5. put this post-receive hook, with your USERNAME, in ~/sites/USERNAME/source.git/hooks and make it executable: chmod +x ~/sites/USERNAME/source.git/hooks/post-receive
  3. I setup a git remote in your local git repo: git remote add publish USERNAME@server.com:sites/USERNAME/source.git
  4. and push locally: git push publish master

That’s it. Seriously. I think it was worth it. The next challenge will be running a jekyll –auto daemon so that only the files that change get regenerated. Cheers!