I saw the github pages of Conor Lamb and he had a nice guide there highlighting the “easy” steps in setting up a “modern”, “not outdated” type of “blog”. Jokes aside, there’s a reason why I decided to do it as well. Thanks Conor Lamb for the guide. It kinda helped! 👍
What’s Hugo?
Hugo is a static website generator that takes a theme, a list of markdown files, and some config and static content and makes it kiss and make a baby which is this site you’re reading now.
What’s github pages
Ever seen one of those “something.github.io” websites? Well, apparently, if you:
- Create a repository in your github account titled
<your account id>.github.io
- Go to repository settings and configure github pages for this repository
- Slap some files in it
- BAM!
There is a build pipeline happening, and the contents of your repository get displayed as a website.
Picking a theme
This small step was actually harder than it sounds. A theme is what people see first, so it has to be:
- Easy to read. There are plenty of aggressive themes with hard to read fonts or too high contrast.
- Tuned for my use case. If I’m gonna write anything, it’s going to involve code, diagrams, maybe charts.
- Uncluttered. The last thing I need is extra large bars at the top of code blocks that seem like code.
- Pretty.
- It … has to work. My first attempt was a disaster.
- License. Almost forgot about that one. I want my content to be of a permissive license. Some of the themes I looked at were GPL family, and I’m no laywer, but I don’t want to get involved with having to have license issues as I use MIT, BSD, CC or WTFPL.
I could’ve also made my own. Although I am already in my pyjamas.
Automated deployments
If you do theme switching until you figure out what you want, you will have the trouble that I had:
your content is in the same place as the config
Managing versions, revering them would be a pain. So I did 2 separate repos. One purely for content, and another one purely for configuration.
It builds a branch called build
in the “content” repository, where all the static files are hosted, as soon as I update any content, or manually run the build.
I’m still getting the hang of it, so here’s how it works so far:
You can add a definition in .github/workflows
directory in your repository, and it will run when certain conditions are met. Here’s mine, for this automatic build. It basically does the following:
- Clones the
configuration
repo - Clones the
content
repo - Clones the
build
branch of thecontent
repo separately - Downloads the latest release of hugo, as a binary, copies content next to config, and runs the
hugo
command, and then copies the artifacts to thebuild
directory - Creates a commit with the changes and pushes it to
build
branch if there are any changes detected
The reason for a separate content
and build
directories from the same repository is that content
is read-only, and I always get the freshest copy, while build
is write-only, and will see incremental updates, trackable in git, to the conte that it manages, without any merge conflicts.