Scheduling posts with Sculpin (and other static site generators)

One of the most difficult things about using static site generators has been handling scheduling posts ahead of time. I have a few ideas about interesting ways to schedule posts, but most of them are very technically complex, so I'm trying to explore a few different solutions, and I'll write them up here as I try them. If you haven't read it yet, check out my post on Starting a Blog With Sculpin so you know the context for what I'm talking about.

The metric for whether or not the scheduling process has been successful is: Can I, ahead of time, trigger a new episode of the Five Minute Geek Show to publish at a certain time? This is important to me, because I have FMGS on a set schedule, but I'm not always at my main computer to deploy then.

Infrastructure

Normally, publishing to the site means just running the publish script locally. My particular publish script generates the new files, moves them into a Git repository, and pushes up the git repo, relying on Forge to catch the Github webhook and deploy.

Because we're scheduling it for the future, we can no longer rely on my local machine being running at the time of the deploy. So we need to find some other way to sync it up.

How to Schedule on Linux

When I first mentioned this on Twitter, Adam Wathan pointed out the at command, which is like a one-off cron job that lets you schedule a command later. I like it, and I'll be planning on that.

So, my command was this:

$ at 10:00
at> cd ~/fiveminutegeekshow.com
at> do whatever commands I want here
at> <ctrl-d>

You can check which commands are scheduled later with $ at -l.

Option 1: Upload the source to the production server and schedule a build

The first option is to get rid of the idea of a "distribution" github repo entirely. We could upload the "source" repo up to the production server, along with its output_prod folder. Then we could schedule a sculpin generate --env=prod command at the given time.

We can just point Forge's web root to be /home/fiveminutegeekshow.com/output_prod, and then every time a new build is made, Forge will be serving the new content.

Option 2: Disable the auto-deploy on the distribution repo and schedule a git pull command

We could keep the situation just like it is right now, disable Forge's auto-deploy, and instead schedule a git pull in the proper directory at the given time.

Option 3: The folder system

Capistrano is a deploy system that has a clever idea: To avoid downtime, every new deploy of the site should have its own folder in a "deploys" directory. Then when it's time to actually publish the new version, all you need to do is symlink your "current" directory (which is what your web server is serving from) over to the new directory. This also makes it very easy to roll back to previous verisons.

We could do the same sort of thing. This is where it starts getting complex, though. We're talking about likely using something like Capistrano or Chef to deploy the code, and then still needing to schedule the symlink in advance. I know someone's going to suggest this way of doing it, which is why I'm bringing it up, but it seems crazy to me.

The current conlusion

For now I'm going to try Option 2. I have an episode going out at 10am Eastern today, so I'm going to see if I can get it set up for this afternoon, and report back here.

UPDATE: Option 2 worked like a charm!