Automating Jekyll deployment, take two

2019-04-22

Back last year, I posted about how I set up a non-bare git repository on NearlyFreeSpeech so I could work on the site from both my laptop and desktop. This has worked fine, but the fact that it's not the 'right' way to do it hasn't sat well with me.

The issue I was having with a bare repository came down to deleting the temporary clone that was used to build the site. Despite working fine from the command line and via SSH, attempting to remove the temporary clone used to build the site gave Directory not empty errors, all related to the .git subdirectory. Because the directory wasn't completely removed, creating the temporary repository failed when the script next ran.

After converting the repository from non-bare to bare, I started with the post-receive hook that I'd first tried (via Bart Lantz). This threw the same error, but worked thanks to the multiple rm -rf lines. Experimenting with adding a delay didn't seem to change much, but I found a very relevant Stack Overflow question that tackled what was likely the same situation. The second answer gave me the solution: rather than using git clone which creates the .git subdirectory that couldn't be removed cleanly, use git archive to export a copy of all the files. This was the key to solving the problem and after a bit of trial and error gave me the final version of my post-receive hook.

#!/bin/bash

# set up variables
REPO_PATH=/path/to/barerepo.git/
PUBLIC_WWW=/var/www
TMP_CLONE=/tmp/repo

# archive the repository to the temp directory
mkdir $TMP_CLONE
cd $REPO_PATH
git archive master | tar -xf - -C $TMP_CLONE

# build the site, putting it in the PUBLIC_WWW directory
jekyll build --source $TMP_CLONE --destination $PUBLIC_WWW

# clean up the temp repository
rm -rf $TMP_CLONE

exit

I'm still not positive what causes the original issue, but other reading I've done makes me suspect that the instance of git running on the server during the execution of the post-receive hook is locking access to parts of the .git subdirectory. This would explain why I wasn't able to replicate the issue on the command line or when running the script via SSH, as well as why multiple rm lines eventually removed the directory. Either way, using git archive is an ideal workaround and it's nice to have learned a little more about git.