How to use GitHub Actions to update a Jekyll blog

Thomas Dickson

2 minute read

Posted on October 8, 2023
Last modified on July 25, 2024

I implemented a GitHub Actions workflow to make it easier for me to update my blog. I’ve previously written here about my blog setup. Since I initially deployed my blog I found running the update script to from a specific machine quite limiting. This post describes how I implemented a GitHub Action workflow to build my Jekyll blog and then copy the files to the Droplet where I serve it.

GitHub Actions is GitHub’s offering to the world of workflow automation and CI/CD. It’s similar to GitLab CI/CD and Jenkins, for example. I’ve chosen to use GitHub actions as I don’t want to change my version control provider and, for a change, I don’t mind using a solution to automate friction away now that I can own the process from first principles. GitHub Actions is also free for under 2000 minutes of use per month so I’m not out of pocket for using it either. Each run of the pipeline takes under a minute, so I think I’ve got quite a few goes to max out my capacity.

The diagram below shows the different steps in the workflow I implemented. I found this post helpful for the first few stages of building a Jekyll website and this one helped show me how to use rsync`¹ to copy the generated files to my droplet.

graph LR F(Action configuration) --> A(Start Ubuntu runner) --> B(Checkout repo) --> C(Configure Ruby) --> D(Build Jekyll blog) --> E(Copy files to Droplet)

I made a few decisions when implementing the workflow:

I abstracted two variables. One was the ssh key which is now interpolated into the command used to rsync files to the droplet. The second was the string that defined the paths that determined what files were going to be copied where. These were both added as secrets within the repo that can be accessed by the workflow.
I wanted the workflow to trigger on any pushes to the gh-actions branch and on PRs to the main branch of my blog repo. The gh-actions branch was where I was devving changes to the workflow functionality so I wanted changes to be tested immediately. I have to be careful with making PRs to main as any would result in changes to the deployed website. I could remove this risk by i) updating the automation to fire on commits to main branch, ii) creating and deploying to a dev environment or iii) making the pipeline fully manual. For now I’m lazy/confident enough to leave this functionality alone for now.

Whenever I see rsync I’m reminded of the classic HN comment about Dropbox. Always good to keep in mind how apparently simple technological solutions can solve big problems in the real world. ↩