Moving to Hugo pt. 2
Feb 16, 2017 · 305 words · 2 minutes read
In part one I wrote a little about my motivation for switching to Hugo. At that point my (limited) experience with Hugo had been mostly positive and I didn’t think I needed to say much about the actual process of the migration.
The full title of this post could be “Moving to Hugo pt. 2: Why I should never have done this or least nuked everything and started from scratch”.
It turns out deploying a Hugo site to GitHub is not as straight forward as using Jekyll. There is a little tutorial that walks through steps for deployment on GitHub. I could have saved some time if I had followed it to the letter.
There are two things I didn’t like and tried to avoid. First, the tutorial uses separate repositories for the content and the site. Second, it then makes use of submodules to link the repositories together.
Hugo also uses submodules for themes and I went in circles yesterday trying to sort out issues caused by the theme submodule. The solution? Fork the theme. Yes, now I have 3 repositories for 1 site…
Anyway, trying to avoid submodules didn’t work out so well because I ran into multiple build errors on GitHub during the migration.
Finally I wound up getting my site to build but the theme wasn’t being applied. It turns out there is a big difference between calling hugo serve and hugo in that the former builds the site with localhost as the base URL. The latter uses the parameter defined inconfig.toml BUT will silently fail if that URL doesn’t end in a slash!
I’m still excited to be using Hugo, but the setup and deployment was not quite as straight forward as I though. But it turns out everything you need to know is in the docs.