On moving to Hugo on GitLab Pages

This week, I took a hiatus from the refactoring fun I’ve undertaken to (finally) move the blog over to a static site generator.

I’ve written before about my plans to move to Hugo, and that’s now complete. Since the beginning of the year, all posts have been written as Markdown files that I can easily grab and format with the necessary front matter. Before then, I hadn’t written very much, and in fact I’ve dropped a couple of old posts that I felt didn’t add to the site in any way.

The site-generation files exist in a GitLab repo. I treat this site as I would any other software project; issues are opened to add or modify things (including posts), a branch is created to address these issues, and when the work is done, the changes are merged into master.

Whenever something happens on master, GitLab’s CI kicks in and a shared runner picks up the job, builds the site, and uploads the public/ folder to GitLab Pages. This is one of the easiest ways to set up continuous deployment for the site, but when I started trying it out there was an open issue to resolve for performance—it could take hours before the changes went live. That’s gotten much better since GitLab 8.9RC3 was deployed, and I only make one post per week so it’s not that big a deal—but if you need to keep things up-to-the-minute fresh it’s not a bad idea to set up a project-specific runner instead to build and deploy your site.

The official deploy date of the site is—as you can see from the 1.0 milestone—Friday, July 1st.

One more thing: the RSS feed for this site will be changing. If you subscribe to the feed, please update your link to


More tk!

Angelo Stavrow

Montreal, Canada
Email me

Tinkerer with a strong interest for development, of both the personal and software persuasion; easily defeated with spatulas. Equal measures enthusiasm and concern for tech's effect on the world. He/him.