Hugo Pipeline Series – Intro
Who is this for?
This is the first part in a series of posts where I’ll describe how I created my personal blog with a fair amount of work to achieve simplicity. The intended audience is:
- Myself (as documentation)
- Someone with their own Hugo blog, looking to improve automation
- Someone interesting in learning one way of working with a Hugo blog
This will be an overview of the different pieces I use, it won’t be a detailed description or tutorial, but I’ll try to link to libraries and concepts.
TL;DR
- Repo is here. README shows how to run it locally
- A build & deploy log is here
Site characteristics
The site I’ll be describing has the following characteristics:
- Annual running cost of nothing, except for the domain name
- Static site (built with Hugo)
- 400+ images
- < 2 minutes combined build & deploy time
- Custom domain with HTTPS
- Lazy loading of images (with blurry preview when JS is available)
- Search with Lunr
- Lightbox for images and code
- Dark/light mode
- Alpine.js for custom JavaScript code
- Cypress tests that run automatically on pull requests
- Lighthouse audits automatically run after deploy
- All code is in a public repo on GitHub
- Runs locally without Internet access
What it doesn’t have:
- Dynamic data loading (except for comments and analytics)
- SPA characteristics (it has full page reloads)
- Offline availability (it’s not a PWA)
- A proper CMS
- Configurable UI, like themes intended for re-use tend to have
A fashion blogger (or other non-technical friend) might view this setup as horribly complicated, but that’s because the complexity is hidden to the user in a typical blogging platform.
Admittedly, I’ve spent some time on this over the years, with small adjustment every now and then, to achieve this level of sophistication and simplicity. It might sound arrogant with “sophistication” and “simplicity” but storing the content as text files instead of in a database and having a static site that can run from a CDN is simple.
It’s sophisticated in that the pipeline is automated and has tests in the same way as our professional applications we develop at work. I’ll create a new branch, do code or design change and make a pull request (PR) to myself. If the tests that run automatically when a PR is created are green, I merge without hesitation. More details coming in future posts… (here is part 2)