Two years ago, my COVID-addled brain initialised this blog. I made some pretty neat adjustments to the theme (we’ve got a cool blinking cursor in the navigation bar), my old posts are neatly organised and still reachable from their original URLs and I even wrote some actual content about how easy it was to set up Hugo.

Unfortunately, upon returning to the blog, I made the following shocking discoveries:

  • Criminally, I had not pushed the blog to a remote, necessitating an archaeological dig.
  • In similar severity, publishing was managed by a mysterious file called bloggo.sh.
  • The scraped Wordpress content was published independently of the new blog.

I am going to blame the COVID for this blatant computer misuse and speak no more of it.


Setting up a blog is a romantic activity best shared with a partner; and I was not alone in my endeavours two years ago. My partner Samantha also set up a nice Hugo blog in our COVID haze. However, Samantha has a much better track record of actually finishing tasks, and returned to theirs to resolve the friction in writing and publishing sap218.uk1 by activating Github Pages on the repository.

I’d used Github Pages in a distant memory that involved an upsetting amount of Ruby and not thought about it since. Samantha assured me that times had changed and together with Github Actions, publishing a blog with Hugo was merely a few clicks away.

I have resolved to try and ditch my Linode (now Akamai) server as running a VPS is a bit 2015 and I have more than enough computers to worry about. Outsourcing the hosting for my blog to Bill Gates’ computer would help me be rid of one of my own computers.

Samantha was right: I quickly managed to get the blog working via Github Pages. I am not going to recapitulate the process here, that is what documentation is for, but in summary:

  • For a start, I actually made a repo
  • I enabled Github Pages from the settings, which prompts selection of a Github Action2
  • I selected the action named “Deploy Hugo site to Pages” and committed the autogenerated YAML to my repo without thinking much about it
  • Once happy that things were rendering OK on the provided github.io domain, I updated the DNS A and AAAA records3 for samnicholls.net to point away from my VPS and toward the required Github IPs, and set up a CNAME for www.samnicholls.net4

Neat. Hands free writing and publishing. Almost all was well.

One minor problem that both Samantha and I have experienced with Hugo is the occasional mismatch between our chosen theme and the version of Hugo used to render the website causing fatal build errors. In my case, they were straightforward to resolve5 but Samantha had such issues in the past they’ve changed to a different theme entirely.

The final hurdle was to restore the “Samposium v1” content by having the Hugo site also serve the static pages that we scraped while the Wordpress blog was still alive. I thought this was going to be quite annoying, before realising we’ve a static/ directory already…

Turns out we can simply6 pour all the files in there.

Two years late but the blog has officially been migrated, and I am one step closer to decommissioning my VPS of 13 years.


  1. A good website for ontology enjoyers. ↩︎

  2. Configuring a publishing source for your GitHub Pages site ↩︎

  3. Don’t half-arse this. I initially put just two of the four Github A records in my zone, but Github’s DNS checking appeared upset by this and my site was left in purgatory while waiting for the additional records to propagate. ↩︎

  4. Managing a custom domain for your GitHub Pages site ↩︎

  5. Uninterestingly, I removed a bit of header that caused an unwanted glyph in the navbar, and changed a partial to take the site.Params object in whole to fix a rather unintelligible “can’t evaluate field align in type []interface {}” error #649ecab ↩︎

  6. When I first checked the v1 content as served from the static/ directory on the github.io website (before I published to my custom domain), I had problems with missing static content. This was because the repo was served from samstudio.github.io/blog, but all the assets from my old blog were littered with URLs expecting to be served from the root. I could have fixed this by rewriting all the static content to use root-relative URLs, but the problem simply went away when I served the content from the root of samnicholls.net as I’d always intended anyway. ↩︎