A couple of weeks ago I noticed a minor but annoying bug on this blog: my previous post did not match the preview I saw when I was writing it. More specifically, the strike through text on footnote 2 was not struck through.

I re-checked the preview in case I had changed something before publishing but the line appeared in the preview. Maybe there's a difference when actually building the site? But no, the built file contained the <del> tag for strike through. OK so we're getting to the likely culprit. The blog is not manually published by me: instead, my CI takes care of building the latest commit of main and publishing the output.

Let's see the Dockerfile for the CI image I use:

FROM alpine:3.18

RUN apk --update add --no-cache zola ripgrep make

Pretty straightforward, an Alpine image with Zola, ripgrep for checking for drafts before publishing, and make because I like Makefiles. Anyway, notice that little number next to alpine? It specifies the version of the image I want to use, which is great to avoid downloading a new image every time there's an update, and keeping a consistent behaviour throughout runs. But what about the packages I'm installing? Those don't have a specified version, and a difference between my locally installed version of Zola and the one installed in the CI image could explain the difference between outputs.

Feeling a bit lazy, I checked the Alpine images and saw that version 3.19 was available so I decided to upgrade and check if that solved my problem. Once update, I pointed the CI to the new image, rebuilt the site, and the bug was still there. I read the logs of the CI building the image and realised it was using version 0.17.2-rc3, so not quite 0.17.2. Problem is I could not be sure that this version mismatch was actually the cause, as I could not find a 0.17.2-rc3 tag on Zola's repo, nor the d7a36ea commit indicated by the package page.

Assuming that the release candidate was close enough to the release version, I built and tested version 0.18.0 in a container and confirmed that it fixed the bug. Knowing this I could have just modified the Dockerfile to build Zola from source or used Alpine's edge repository, but I wanted to know the cause of the problem.

It occurred to me that my local version may not actually be 0.17.2: I build directly from source as currently the Fedora package is unmaintained. I checked and indeed, the local HEAD was several commits ahead of 0.17.2. Perfect, they probably introduced a fix that I unintentionally added to my local version! Except they didn't: none of the commits touched the source code, only the documentation. And more importantly, no changes to the dependencies were made, which could have been the cause since Zola uses pulldown-cmark to parse the Markdown files.

But what if it was a dependency mismatch? Not being familiar with how Rust software is built I was surprised to not see pulldown-cmark on the Cargo.toml at the root of the repo, though a quick ripgrep query pointed me to components/libs/Cargo.toml which specifies version "0.9". According to the Cargo reference, this is not exactly version 0.9 but rather a range of versions, allowing any version above or equal to 0.9 but below 1.0.

We're getting somewhere. Thankfully, while the Alpine package points to a mysterious commit, it does have a log of the build which shows us that it was built with version 0.9.2. A quick look at my local Cargo registry showed I have version 0.9.3.

Did this version difference cause the difference in rendering? According to the release page, yes: 0.9.3 introduced the option to strike through text with a single tilde. Checking the Markdown source I indeed used a single tilde for markup: my editor strikes the text through and my Zola version, built with pulldown-cmark 0.9.3, also renders it with a nice line through the text. I very rarely use strike through so I didn't know the compatible way was to use two tildes. TIL!

While I decide whether to update the image and how, I simply added the missing tildes so the post matches the preview.

Before finishing the post, another question popped up: when building Zola inside a container I noticed the documentation says to run cargo install --path . --locked, where the --locked version indicates that an up-to-date Cargo.lock is required. This lock file does specify to use pulldown-cmark version 0.9.2, so how could I have gotten 0.9.3 when building locally? My shell's history says I simply omitted the --locked option! No idea why, but that's the actual cause of this discrepancy. Who would have thought that lock files are useful for consistency. :)

The picture

Filippo Valsorda, besides producing great software like age, also has his own blog, in which he often finishes the posts with a photo unrelated to the post. I like this idea so I'm shamelessly copying it taking inspiration and start by adding a French touch with a view of the Panthéon.

A far away photo of the Panthéon