The story from yesterday actually started by trying to upgrade Gitea from the 1.14 branch which I was running, precisely 1.14.7 by the time of writing, to the branch 1.15, or more precisely again, to the version 1.15.4.

I postponed the upgrade to the 1.15 because even though Gitea seems to follow semantic versioning, or semver for short, in which a change in the middle number is considered a MINOR upgrade that's defined as providing new functionality in a backward-compatible manner, upgrading is never a totally safe operation. Not even when just the third part of the semver compatible version changes, which should contain only bug fixes, but the risk might be lower.

The risk might be higher here however, since the community behind Gitea provides backports of fixes to both branches mentioned above - the 1.14 and 1.15, meaning both branches differ in at least one major way that could potentially break the setup.

That's why I was reluctant to do the upgrade sooner, as I was not really in the pressing need for the new features implemented in the 1.15 branch, although there are definitely a few of them I want to try out. On the other hand, I needed a stable place to push my commits to during the development over the previous two months.

Upgrading anything needs time (and backups!)

Although my VPS provide snapshots, they are not automatic, which is sad. But even when they are automatic, the period the snapshots are being taken could be one week. It is enough to get back to business in case of some really serious hiccup, but it is not enough to prevent most business-critical data to be preserved.

I prefer 12 or 24 hour incremental backups, for which I either use good old rysnc or restic most of the time. I decided to do a tagged restic backup and at the same time, a gitea dump command. I am running Gitea as a docker container, so I did a dump as well, just to be safe:

docker exec -it --user git gitea-server-1 /bin/bash

Now inside the container navigate to the gitea executable:

cd /app/gitea

Take care, the following operation might consume a lot of storage:

gitea dump --file gitea-dump.zip
exit

Copy the backup outside of the container and remove it from inside:

docker cp gitea-server-1:/app/gitea/gitea-dump.zip .
docker exec -it gitea-cp rm /app/gitea/gitea-dump.zip

Now the data should be recoverable if the damage occurs during (or right after) the upgrade.

Upgrading

Upgrading the Gitea is very easy, in my case it is just changing the version inside docker-compose.yml and running the following:

sudo docker-compose up -d --build

The command ran without any problems and the upgraded Gitea version shown no problems after a few hours of usage. Do not forget to delete the dumps before the restic cron job picks them up!