« The blog zygote »

19 July 2012
Another blog to read, why not?
Another blog to read, why not?

Putting together all the moving pieces to get this blog to work the way I wanted took a little while. In the interest of sharing how I did it in case this helps others, I thought I’d share the approach I took.

Overview

So, here’s the way it goes down: - I’m using jekyll to publish. If you’re unfamiliar with it, jekyll essentially lets you write your pages as templates, and generate a static HTML site from the ‘source’ of your web site. I don’t need anything beyond static HTML, and engines like disqus could meet my needs in the future if I needed commenting or the like. - I keep my jekyll site source code in a git repo on my shared hosting provider. - On my shared host, the central repo has a hook which pulls changes into a staging jekyll directory. - An auto-refreshing jekyll process detects changes and generates my site, spitting the results into my public_html directory.

How bout them details

The git workflow

I owe most of this workflow to somebody else. Go there in order to learn about how the working copies, hub, and prime repositories are set up. Mine is set up exactly this way, with the added cog in the machine that is jekyll.

It is worth noting that although I’m using this workflow, the only change I had to make was to append this to my .gitignore:

$ tail -n1 .gitignore
_site

That’s it. The rest works exactly as described in the previously mentioned post.

The jekyll side

Although the site now resides comfortably in a git repository, the issue of site generation is still with us. First let’s look at the set up:

  • On my shared host, my main git repository resides at ~/repo/blog.git
  • A hook pulls new changes into the hub remote, which I have at ~/opt/src/blog
  • Within the hub remote directory, I have left a detached screen session running the command jekyll --auto ~/public_html/blog

So, what does this create? Why, good sir, the following workflow:

$ git pull ty@sharedhost:~/repo/blog.git blog
$ cd blog/

... Make edits, change CSS, eat cake ...

$ git add -p
$ git commit
$ git push origin master

What happens next is this:

  • Git origin repo receives push
  • Post-update hook pulls changes into hub
  • Jekyll process running in detached screen senses any updates, and auto-generates renewed HTML into ~/public_html/blog

Nice, huh? For anyone who may wonder why this seemingly involved process is the route I took:

  • Static HTML → nice and fast page rendering, I don’t need anything else.
  • By the same token, there shouldn’t be security issues like SQL injection if I had used something like Wordpress… right?
  • My blog is now under version control, which means I can edit from anywhere and branch ideas into other git branches.
  • Git version control also means I have multiple copies of my entire blog around for backup.

Overall this system has worked very well and I’m quite happy with it.

ty@tjllgmail.net