How to use GitHub Actions to update a Jekyll blog
In this blog post, I explain how I implemented a GitHub Actions workflow to automate the updating of my Jekyll blog by building it and transferring files to my Droplet using `rsync`. I configured the workflow to trigger on pushes to the `gh-actions` branch and on pull requests to the main branch, ensuring efficient testing and deployment of changes.
Updating a blog by running scripts from a specific machine is limiting. This post describes how to use GitHub Actions to automate the process—building a Jekyll blog and deploying files to a server. (If relevant: I detailed my original blog setup here.)
GitHub Actions provides workflow automation and CI/CD, similar to GitLab CI/CD and Jenkins. It integrates with your existing GitHub repository, avoiding vendor lock-in, and offers a generous free tier (2,000 minutes per month). For this workflow, each run completes in roughly 45 seconds, leaving substantial headroom within the free allocation.
The diagram below shows the different steps in the workflow I implemented. The workflow draws on two resources: this guide for building Jekyll, and this one for deploying with rsync1.
I made a few decisions when implementing the workflow:
- I stored two configuration values as repository secrets: the SSH key for authentication, and the rsync parameters defining which files to copy. This keeps sensitive data out of version control.
- The workflow triggers on two events: pushes to the
gh-actionsbranch (for testing changes to the workflow itself) and pull requests to main (to validate changes before deployment). PRs to main carry deployment risk, which could be mitigated with a separate staging environment or manual approval step, but the current setup reflects the blog’s low traffic and low stakes.
Footnotes
-
Whenever I see
rsyncI’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. ↩