Hugo Static Site on GitHub - Continuous Integration/Deployment

After migrating the blog to Hugo and making some custom changes, it was time to develop the CI-CD pipeline. The key objectives for my CI-CD pipeline were

to be able to build the site locally and

to be able to build the site remotely on an integration server

Build Locally

More often than not, I use my computer to post stuff on this site. As I already have the site repo and Hugo on my machine, I run the hugo server --buildDrafts while editing the repo with a browser window open on my secondary monitor to monitor the edits. This is the simplest no nonsense editor setup I use.

I wanted to be able to build the whole site locally when I have everything I need already. It didn’t make much sense to push the changes to GitHub and have Travis-CI handle the build and publish part. I don’t have any tests and sanity checks built on the CI server anyway.

I built the following script to automate the build and deployment activities. This lets me choose between a local or a remote build.

Notice the git pull at the very beginning. It is added so that the local code is updated with any changes or updates made from other workspaces or remote builds.

If a remote build is requested, this script gives out a message to pull the changes, if need be. I don’t pull the changes separately as this script pulls it anyway.

The [skip ci] text in the Git commit message notifies Travis to ignore the check-in.

Build Remotely

For the times when I don’t have access to my computer but still wanted to update the site, I setup the CI-CD pipeline. This allows me to post from virtually anywhere, any device as long as I can connect and commit to GitHub repo. GitHub’s markdown preview acts as a basic WYSIWYG editor except that it doesn’t understand Hugo’s shortcodes which honestly is not a big inconvenience.

Setting this up at a high level was as easy as -

Creating deploy keys for the repo so that Travis can deploy the built site. The public key goes in GitHub and the private key goes to Travis.

Encrypting the private key so it remains secret and only Travis can decrypt it. This needs travis gems installed and of course, Ruby as well.

Building the steps that Travis will take whenever it finds a commit to the repo.