Forgejo on blog.iankulin.com

Upgrading to Forgejo 7.0.1

Mon, 06 May 2024 00:00:00 +0000

It’s not that long ago that I wrote about doing routine upgrades on containerised web apps using Forgejo as an example as I upgraded Forgejo (my git repository manager) between patch versions of 1.21, then a few days later, they dropped 7.0.0

They say the major version jump is due to it being an LTS (long term support) release, and changing to semantic versioning 2.0.0 , but that doesn’t quite explain it to me, and I assume this is partly signifying the fork’s drift away from the gitea codebase. In any case, the upgrade to 7.0.0 it does involve some breaking changes, and signifies to me that a lot has been on, which makes me keen to wait for a patch release (I’m always keen for other people to debug these things) which has now landed.

The reason I think the upgrade process is worth mentioning, is that the steps we went through to move from 1.21.0 to 1.21.8:

docker compose down
docker pull codeberg.org/forgejo/forgejo:1.21
docker compose up

will not work this time, and gives me the excuse to talk about container tags.

Container Tags

When the developers had built their release for 1.21.8, they would have pushed the exact same image to:

codeberg.org/forgejo/forgejo:1.21.8
codeberg.org/forgejo/forgejo:1.21
codeberg.org/forgejo/forgejo:1
codeberg.org/forgejo/forgejo:latest

that way, people like me who had specified codeberg.org/forgejo/forgejo:1.21 in their docker-compose.yml files just had to down/pull/up to be in business.

If they had released another patch version, say 1.21.10, they they would have pushed the new image to:

codeberg.org/forgejo/forgejo:1.21.10
codeberg.org/forgejo/forgejo:1.21
codeberg.org/forgejo/forgejo:1
codeberg.org/forgejo/forgejo:latest

i.e. the old 1.21.8 image would have stayed the same, so anyone who had depended on that not changing will still be fine, but people like me who want all the patch versions updated (but not a minor version change) would get the new one.

Normally you can just click on ’tags’ for an image on Docker Hub, but since this one is hosted on Codeburg’s Forgejo instance, you need to go https://codeberg.org/forgejo/-/packages/container/forgejo/versions to see all the tags they’ve pushed to.

Upgrade steps

The extra step we’ll need to go through this time is to decide what level of version we want to specify in our docker-compose. I’ll stick to specifying to the minor version so my new docker-compose.yml will be:

version: '3'

networks:
 forgejo:
 external: false

services:
 server:
 image: codeberg.org/forgejo/forgejo:7.0
 container_name: forgejo
 environment:
 - USER_UID=112
 - USER_GID=103
 restart: always
 networks:
 - forgejo
 volumes:
 - ./forgejo:/data
 - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro
 ports:
 - '80:3000'
 - '2200:22'

Once that decision is made, it’s just the same:

backup the LXC
docker compose down
docker pull codeberg.org/forgejo/forgejo:7.0
docker compose up
Then some testing

We could probably skip that pull step - when you compose up the system would notice the version change and pull it for us.

My Web App Update Process

Mon, 01 Apr 2024 00:00:00 +0000

I’ve settled on a very standard, reproducible setup for services in my homelab. This post looks at that, then runs through the update I did today to Forgejo which only took a few minutes and felt relatively risk free.

Standard Setups

My system is based around Proxmox. I have three physical machines - one for production apps, a production spare, and a development/testbed machine. A Synology NAS serves for backups. Moving a VM or LXC between the machines is trivial; but it’s done manually - the machines are not clustered for high availability.

Most workloads are Docker containers inside an LXC. This works fine with a couple of caveats. I have an LXC template saved with Docker and Tailscale installed, my non-root user added, the mount for the NAS, and SSH keys. Setting up a new app starts with a full clone of this, a dpkg-reconfigure openssh-server and tailscale up and changing the root & non-root users’ passwords.

Next I create a sub directory for the app and write the docker-compose.yaml in there. Then it’s just a matter of docker compose up -d. If there’s any data, it goes in a another sub directory off this one.

Unless I need something else, nightly backups to the NAS happen automatically for all the VMs and containers handled by a setting in Proxmox.

Upgrading an App

I’ve noticed a couple of posts about a new release of Forgejo on Mastodon in the past few days, so I figure I should look at that. My version is 1.21.1 and the new one is 1.21.8

Because of semantic versioning, I’m confident this is not going to break anything, but I check the release notes anyway. It looks good.

Backup

I jump into the Proxmox web gui and make a backup of the container.

Docker Compose

I ssh in to look at the image tag in the docker-compose.yml file. The reason I’m interested in this is that if the compose is set to codeberg.org/forgejo/forgejo:1.21.1 then it will be locked into that patch version, but it says codeberg.org/forgejo/forgejo:1.21 so we’re good.

Now I take the service down from the CLI with sudo docker compose down, then pull the new image with sudo docker pull codeberg.org/forgejo/forgejo:1.21

The to start it again, it’s just a docker compose up -d and we’re live again.

Testing

My testing of this was pretty brief since (a) I’ve got high confidence in the developers at gitea and forgejo and (b) this app gets pretty much daily use so if there are issues I’ll surface them pretty quickly, (c) anything I’m actively working on had full git histories on my laptop, and (d) the releases since my last update are pretty much just bug fixes.

Nevertheless, I clicked around the web gui, and tried some pushes, pulls and clones and everything seemed fine.

Conclusion

I’m very comfortable with the way I’ve put all this together now. It’s a reliable, easily managed setup that makes maintenance like this simple and safe.

Gogs, Gitea, Forgejo

Mon, 18 Dec 2023 00:00:00 +0000

I’ve been really pleased with Gogs - it’s lightweight, was simple to spin up, and has worked perfectly. But then this morning on Mastodon, there’s a post from @Codeberg.org describing a security vulnerability in their Git hosting project Forgejo. This issue also apparently affects Gitea and Gogs - what’s up with that?

I actually already did spend a bit of time comparing Gogs and Gitea before deciding on Gogs, since I’d heard of people running Gitea over the past year or so, but only seen that Gogs seemed to be popular with self-hosters in a Lemmy post I’d read. My first impression was that Gitea was more focused on CI/CD and seemed to have a more complicated install process.

What I didn’t do, was think about the project management and teams. It turns out that Gitea was forked from Gogs by contributors in 2016 due to disagreements about the project management. Then at the end of 2022 Forgejo was forked from Gitea due to Gitea moving the trademarks and domain into a company providing Gitea support.

The CVE announcement from Forgeo, while a little snarky about their ancestors, does give the impression of a functional organisation that’s able to deal with issues as they come up. It’s a credit to the group to be in that position after just a year, and their repo (which is dogfooded) seems plenty active.

I’ve only just started on Gogs, so it’s still easy to move if that’s what I decide. I guess my learning from stumbling upon this security announcement is more that I should:

take into account more than just project features when making these decisions
I need to be subscribed to the channels where I’d learn about security issues in the projects I’m using and their major dependencies.