I Fucking Hate Hugo

It’s literally been 6 years since I wrote a blog post. Blogs are kind of over, and no one is ever going to read this. If someone does end up reading this, that someone is likely an AI so lol I guess.

Anyway, I fucking hate Hugo. Now don’t get me wrong, all the shit I said in my previous posts about how it’s cheap and fun to host your personal website in an S3 container using a static site generator are still kinda true. I think I maybe just picked the wrong site generator, and then stopped having the motivation to change it.

The Story

I set my PGP encryption keys to expire periodically, and today it expired. I went through the relative hassle of figuring out how all of that works again and documented it as best as I could in Obsidian for posterity. That led me to the trusty website, who was advertising a key that couldn’t be used to encrypt anything for me.

“Let’s fix that!” I said, with some enthusiasm.

Now, part of this is definitely my fault. There are definitely elegant ways around the problems that I encountered here, and I think I even stumbled upon one of them and used it to fix the issues I was having. I am also aware that Hugo hasn’t released a major version yet, so all of their configuration directives and product features are subject to change - not to be relied upon.

But that’s the thing - my use case is literally not updating my website for years on end. I need to rely on the underlying framework to stay relatively static during that time because otherwise, I need to spend a bunch of time fixing my configuration so that the framework works before I can get around to the relatively simple work of updating the content of a fucking website. It’s markdown, after all. It’s supposed to be easy.

So getting back to it, I go to run Hugo on my home server where it is installed locally. Unbeknownst to me, Hugo jumped quite a few minor versions in the last 11 months, and some of those changes wrought havoc with the configuration file syntax. This is fine for me - I guess I could just update my config files. However it’s not really fine for the theme I’m using.

My CI build pipeline clones the theme’s git repo and takes it as is. The theme apparently hasn’t updated to the new configuration standard, and I cannot be bothered to throw in a push request to fix that. Therefore, I can’t run the latest version of Hugo in order to build my website anymore.

The Solution

At some point in the distant past, I had made a Dockerfile that builds a version of Hugo that works perfectly. After a bit of testing, I was able to get the theme working properly. What about the CI pipeline, though?

For that, I needed to make some changes.

For years, I had had a GitLab runner installed on my home server that was configured to do the AWS and Hugo shenanigans for me. This is, of course, sub-optimal because the dependencies of the project aren’t represented in the code. We have a new dependency now on a version of Hugo that works with my theme, so it’s important that that’s committed to the repository.

What I needed to do was reconfigure the CI pipeline to use my shitty Hugo docker image instead of trying to build it locally. An added bonus here would be that if I could get this portable enough, I wouldn’t need to have a local GitLab runner to make the thing thing.

I found this really helpful video, and along with a lot of fucking yelling and documentation reading, was able to piece together a new .gitlab-ci.yml file that looked startlingly similar to the one I started with.

Before

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

stages:
  - build
  - deploy

variables:
  GIT_SUBMODULE_STRATEGY: recursive

build:
  stage: build
  script:
    - hugo
  artifacts:
    paths:
      - public/
    expire_in: 1 week

deploy:
  stage: deploy
  script: 
    - aws s3 sync --acl public-read --sse --delete  ./public s3://$S3_BUCKET_ID/
    - aws cloudfront create-invalidation --distribution-id $CF_DISTRIBUTION_ID --paths '/*'
  artifacts:
    paths:
      - public/
    expire_in: 1 week
  only:
    - tags

After

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

stages:
  - build
  - deploy

variables:
  GIT_SUBMODULE_STRATEGY: recursive

build hugo image:
  stage: .pre
  image: docker
  services:
    - docker:dind
  script:
    - echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin
    - docker build -t $CI_REGISTRY_IMAGE .
    - docker push $CI_REGISTRY_IMAGE
  when: manual

build:
  stage: build
  image: $CI_REGISTRY_IMAGE
  script:
    - hugo
  artifacts:
    paths:
      - public/
    expire_in: 1 week

deploy:
  stage: deploy
  image: 
    name: amazon/aws-cli
    entrypoint: [""]
  script: 
    - aws s3 sync --acl public-read --sse --delete  ./public s3://$S3_BUCKET_ID/
    - aws cloudfront create-invalidation --distribution-id $CF_DISTRIBUTION_ID --paths '/*'
  artifacts:
    paths:
      - public/
    expire_in: 1 week
  only:
    - tags

Closing Thoughts

I wouldn’t have had to have done any of these things had Hugo been a stale, changeless platform, or if it had a deeper commitment to not breaking backwards compatibility. It isn’t, and it doesn’t though, and I did kinda already know that. It’s part of the reason why I have come to dread updating any part of this website. There’s a lot to re-learn and figure out and reverse engineer from the scanty, often smug, documentation I leave for myself.

These kinds of problems are part and parcel of using open-source software platforms at any advanced level and that is what I signed on to do, knowingly or otherwise. Talented engineers find their way around stupid shit like this all the time – and so did I.

That all said, I feel like Hugo is completely out of step with the use case of running this website. This website is detritus from a time where I felt my personal brand mattered to anyone, or that people might do a deeper search for me beyond what they could find on LinkedIn or Twitter (fuck you Elon, it’ll always be fucking Twitter to me you parasite).

This website doesn’t change any more than annually, and when I change it, I don’t want to have to spend 2.5 hours engineering a solution to the latest problem posed by this technically complex bundle of internet thoughts.

Or maybe I do. Maybe I have just changed so much in the 6 years since I posted about anything that the idea of doing this kind of work is no longer appealing.

This website and the theme I chose for it is still very pretty to look at, and revisiting it has been kind of fun. It’s also gratifying to see how cheap it is and how fast it loads. I guess in the end, I don’t really fucking hate Hugo. I hate having to have my time dictated by things that are beyond my control. This is no longer fun for me – the way it used to be. I have changed, and this website (and the technology that powers it) hasn’t.

Maybe it’s time for a change.