A couple weeks ago I migrated myself off Github and onto self-hosted Forgejo. Today I took care of a lot of the consequences of that. I’ll spare you the details, because it was just the same issue presenting itself differently across mutliple project repos, namely:

Golang names packages by their repository URLs.

This is great as long as your code lives at Github, forever. It’s less great when you decide to move everything from one place to another. And yes, I know that you can alias packages; I did that once before, back when I first started writing non-toy software in Go, which was also around the time that I migrated to Github, because it finally felt safe to use as a stable platform.

Oh well, I got about a decade out of it anyway.

This kicked off today instead of when I did the Forgejo migration because today is the day I decided to update my main machine to rootless podman. Thus requiring rebuilds of my running containers, which in turn required me to fix all the packages that those containers were built from.

petrel was at the bottom of the stack, so that my local gnatwren could be updated and rebuilt. Tagged new versions of both those (no changes other than the module renaming).

After that it was time to rebuild Thrasher’s backend container, which initially meant making the same sorts of updates to thrasher-media-service (aka tms). But I had last updated that codebase before I started making changes to thrasher-media-catalog (aka tmc) in support of the non-music media updates that are in progress. So I had to patch tmc into a stable/usable condition and cut a release of it, so that I could then make a few more updates to tms and get it building outside of a Go workspace context.

(I didn’t have to do that last part, but it’s nicer when things are clean so that there’s a stable point to return to just in case you end up taking a months-long break from planned work for some crazy reason.)

That finally got me to the place where I could also tag a new release of tms.

Forgejo upgrade

At that point I found myself wondering if there had been a new Forgejo release in the ~2 weeks since I stood up my instance. And there was, 14.0.4.

I read over the upgrade docs before deciding to do the initial setup, so I had a decent idea of the process. My big question/worry had to do with the fact that the app config file lives inside the container, which means that you get a new default everytime you update the base image. I hoped (and trusted, until proven otherwise) that the devs had made good choices that would make replacing it with my old config easy. So I did the following:

  • Re-pulled the base image to update it
  • execd into the running container to handle the pre-upgrade chores, as described by the docs
  • Moved the dumpfile and the current config file to the /data mountpoint, which I have configured as a podman volume so that it persists across containers
  • Stopped the current container (simply named forgejo)
  • Started a new container with the same command as the previous one, but changing the name to forgejo14.0.4 (a pattern I will continue to use)
  • execd into the new container
  • Moved the new config to a backup filename, then Copied my old config into the proper config location
  • Restarted the container

To my delight and mild surprise, everything worked.

Also, I completely forgot what the original change I wanted to make that spurred all this. I assume I’ll remember later :)

EDIT: a caveat!

It turns out that updating the image generates new SSH host keys. I would have figured this out if I had thought about it more carefully, but I didn’t.

They live at /var/lib/gitea/ssh/, so next time I’ll know to copy them in and out on upgrade to prevent having to edit known_hosts on every machine that touches this server.