Preamble
In the before times (2022 and before), this blog was hosted on a WordPress based platform. It was always meant to be a place that was easy for me to dump my technical projects, thoughts, anything really. I’ve maintained a presence on this domain for over 4 years and written less than 2 posts per year. Why?
I think the answer was in the barrier to entry to start writing on the site. First, there’s the login to Wordpress. Then the update notifications for themes I’m not even using (but can’t uninstall without breaking the site), plugins that barely see any use - why did I have email alerts configured anyway? The only alerts I got were requests to moderate spam and update notifications. The one post I had with real comments on it, only had them because I had shared the post on Reddit. Reddit already has comment functions, why had I enabled comments here too?
Ultimately, I think the WordPress platform is fantastic, but also far too much maintenance for someone who both works and hobbies in the tech space and just wants somewhere to write. I know I’m not alone in this line of thinking. So I decided to move to Jekyll.
Jekyll
Jekyll is a static site generator. Meaning you give it content, a layout, some templates and a theme. You run a build command and, presto, you’ve got a directory filled with files that contain your website - with no server-side code. It’s pretty great and easy to get started with. In my case, I went looking for a theme and followed their instructions to get started - you can find the Chirpy theme linked at the bottom of all pages, it basically boiled down to cloning their repo and running a setup command. Then, customise some settings and you’re good to go!
I particularly like the generated static site approach because, when it comes down to actually sitting down and writing, there’s so little I can get distracted by. I’m sat with a text editor, a tiny amount of metadata at the top of the file, and a Markdown syntax cheat sheet. That’s it. I could even go a step further and choose to write specifically on a low-spec machine. However, there would then be a task to re-build and re-upload my site to a web host each time I write a post, or submit an update, if left unchecked… Automation has been cropping up more often in my professional life than ever, so this is a good opportunity to apply some of the same thinking! More on that later.
GitHub
GitHub has come a long way since it started. I recall days of free users being restricted to only public repositories. Those days are no more. So, the code for my site is now held in a private GitHub repository.
It would be tempting to think of GitHub as a reliable repository that can be trusted to keep your content safe. It is not. Microsoft could choose to end the offering at any moment. So, if you’re following in my footsteps, be sure to keep your code somewhere else, too. That goes for any project, not just websites.
One of the great things about the current free GitHub offering, however, is the ability to post to webhooks upon certain actions - including when a commit is pushed to the repo.
Automating re-deployment
I alluded at webhooks being the answer to the remaining barriers in the ultimate goal of making the maintenance of this site simple. At first glance, one would think this solution is easy: stick a script that regenerates the site on a public URL - no parameters, just a call to rebuild and output the result. Surely that’d be easy…?
Nearly. This was my first approach and, when I tested the webhook locally, it worked just fine. I could curl or wget the URL, and in a relatively short time receive the output from my script giving the output of the build process. But when I tried this in GitHub, I’d never get a successful output on the webhook despite the build working correctly. What gives? Turns out, there’s a timeout on how long a webhook is allowed to wait before receiving the final response from the server. And my build process was taking too long for the webhook to give the response synchronously when called. Bugger. What now?
Asynchonous updates and more webhooks. Am I crazy? Maybe. Does it work? Yes! Big thanks to Discord also providing webhooks as part of their free offering. The solution I ended up designing works as follows:
- Push commit to GitHub
- GitHub calls a webhook on my web server
- The webhook on my web server asynchonously starts the build process, and immediately responds successfully to the GitHub webhook caller.
- The build process completes, capturing the output, and submitting it as an attachment.
- I get a smile on my face, as I get an automated notification telling me the build was successful moments after pushing new code.
Conclusion
Perhaps what I’ve ended up with here is overkill. Jekyll is built in such a way, that I could’ve used GitHub itself as my web host. I may still end up doing so for individual projects in the future, it’s quite a nice system. I just didn’t like the idea that, should the GitHub free offering change in a way that breaks the system I’ve built, that I would have to rearchitect my approach.
I’m not even certain that I’ve fixed the root problem that I was trying to address, which is that I wasn’t posting to my blog at all. I transitioned this site in June 2023, and only finished this article today in November 2025. Perhaps the problem was never the tech? Only time will tell.