Last week I updated my blog for the first time in a long time - so long that I had forgotten exactly how to run and build it. (pelican -rl content is the right answer for my current directory structure.) Once I figured that out, I wrote my post and figured it was smooth sailing from there. Alas, recently GitHub Pages has changed from its "classic" workflow of deploying from a specified branch, to some GitHub Actions-based workflow. I can't exactly figure out what's going on, but I know it uses Jekyll, which my site doesn't use. So I had to look into a custom Github Actions workflow to make my site go.

Initially I thought I could just use a static workflow since I already had the site build artifacts in /output. But for some reason this wouldn't work. I eventually realized I had to switch my site settings to use Source: GitHub Actions. I also wanted to upload only the /output directory, not my entire repo, so I changed around my directory structure; previously I had my pelican conf and content in a /pelican folder and routed build output to the top-level directory. Now I have pelican conf and /content and /output all at the top level. After that, I simply needed to specify the /output directory in the static.yml script, for the step where it packages up the build artifacts.

I also looked into using one of the several Pelican build Actions in the Marketplace. But reading through what they actually do, I noticed that they built the site in a container and ultimately pushed the artifacts to a branch, relying on the classic GH pages deployment behavior - no improvement over my current status. Looking around a bit more, I see now that when writing a workflow, I can insert shell commands directly with runs: , I'm not only restricted to using actions (uses:), so that is a path I might explore in the future. But for now, my blog works and I'm not inclined to mess with it. 🥳