Gogs migration to gitea - part 1
For a longer time now, I’m using gogs to host my git code. However, since beginning of this year, there are some problems. Mostly, that I can’t update anymore to the next versions of gogs (+0.12.1). Besides this, are there some features that I really want to use. These feature has been requested, but I heard, that the core developers isn’t supposedly a nice guy1 and does not implement them. Long story short: A fork was created: gitea.
In this post, I try to figure out if a migration is possible or not. The fork was some time ago and there were change made, that break the migration: Meaning at some point it is not possible to switch anymore. This point was fork release 0.9.146 for gogs.
Here is the catch, I’m using the version 0.12 at the moment. So let’s hope that the migration is working. Main problem is that I need to start with gitea in version 1.0 and slow migrated to the latest version. However, it might be some trouble because the database schema diverting quite a bit.
First is to reproduce my production state on my laptop locally. I replace the gogs docker image with the gitea image and try to see what’s happening. On the website from gitea, a docker-compose example is presented that I’m using for this.
docker-compose stop gogs
Rsync the data down to the example docker-compose file of gitea. Next is to rename the given databases to the right version.
gogs-data > $ mv gogs/ gitea
I forgot to upgrade the path of the log file and run into follow error:
gitea | panic: mkdir /app/gogs: permission denied gitea | gitea | goroutine 1 [running]: gitea | panic(0x55db51367260, 0xc4203a80f0) gitea | /usr/lib/go/src/runtime/panic.go:500 +0x1a5 gitea | code.gitea.io/gitea/modules/setting.newLogService() gitea | /srv/app/src/code.gitea.io/gitea/modules/setting/setting.go:794 +0xdda gitea | code.gitea.io/gitea/modules/setting.NewServices() gitea | /srv/app/src/code.gitea.io/gitea/modules/setting/setting.go:943 +0x1b gitea | code.gitea.io/gitea/routers.NewServices() gitea | /srv/app/src/code.gitea.io/gitea/routers/init.go:37 +0x16 gitea | code.gitea.io/gitea/routers.GlobalInit() gitea | /srv/app/src/code.gitea.io/gitea/routers/init.go:47 +0x158 gitea | code.gitea.io/gitea/cmd.runWeb(0xc4202eb900, 0x0, 0xc4202eb900) gitea | /srv/app/src/code.gitea.io/gitea/cmd/web.go:158 +0xa7 gitea | code.gitea.io/gitea/vendor/github.com/urfave/cli.HandleAction(0x55db513819e0, 0x55db5147be68, 0xc4202eb900, 0xc4201add00, 0x0) gitea | /srv/app/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:471 +0xbb gitea | code.gitea.io/gitea/vendor/github.com/urfave/cli.Command.Run(0x55db50e4ee34, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x55db50e703e1, 0x16, 0x0, ... ) gitea | /srv/app/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/command.go:191 +0xcc9 gitea | code.gitea.io/gitea/vendor/github.com/urfave/cli.(*App).Run(0xc420377040, 0xc42000c140, 0x2, 0x2, 0x0, 0x0) gitea | /srv/app/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:241 +0x6a5 gitea | main.main() gitea | /srv/app/src/code.gitea.io/gitea/main.go:42 +0x356
When evertyings was done proper, this should look like this:
docker-compose up [+] Running 1/0 ⠿ Container gitea Created 0.0s Attaching to gitea gitea | Dec 29 21:22:29 syslogd started: BusyBox v1.24.2 gitea | Dec 29 20:22:29 sshd: Server listening on :: port 22. gitea | Dec 29 20:22:29 sshd: Server listening on 0.0.0.0 port 22. gitea | 2021/12/29 21:22:29 [T] Custom path: /data/gitea gitea | 2021/12/29 21:22:29 [T] Log path: /app/gitea/log gitea | 2021/12/29 21:22:29 [I] Gitea v6aacf4d2 gitea | 2021/12/29 21:22:29 [I] Log Mode: File(Info) gitea | 2021/12/29 21:22:29 [I] Cache Service Enabled gitea | 2021/12/29 21:22:29 [I] Session Service Enabled gitea | 2021/12/29 21:22:38 [I] Git Version: 2.8.3 gitea | 2021/12/29 21:22:38 [I] SQLite3 Supported gitea | 2021/12/29 21:22:38 [I] Run Mode: Production gitea | 2021/12/29 21:22:39 [I] Listen: http://0.0.0.0:3000
Now you should be able to run the webserver. I’ve tried to log in, however, the release databases schema seems invalided to the running version. Which makes sense, there have been some upgraded happening between these versions.
Maybe the database was left in an inconsistent state after I’ve tried to upgrade to 0.12.1 earlier this year. That makes the hole things very messy now.
I could try to make sense of the database’s schema and see what have changed, or I start anew. Okay, let’s check the database thing first. What version do we have? We can use
.colume for some better formated output:
sqlite3 gogs.db .header on .mode column SELECT * FROM version; id version -- ------- 1 19
Okay, when we look at gitea, we have what version? 170? Fuck, but that’s for the latest version. When we jump back to version 1.0.2, we see that the version is 4 and the migration scrips are executing to 13 or 14.
However, there is about of different news to this: that is the following:
Hi there, thank you for using Gogs for so long! However, Gogs has stopped supporting auto-migration from your previously installed version. But the good news is, it’s very easy to fix this problem! You can migrate your older database using a previous release, then you can upgrade to the newest version.
Yacks… Meaning that we need to understand how the codes does perform the migrations? Sight. That’s going to be a hack.
At this point we can do two things: Revert the changes of the databases to a state in which the migration script can handle the migration or setup new and populate the new gitea with the old data. This is it for now!
From what I have seen in the git repository of the project, I can’t confirm it, but I haven’t seen very little of it. From the little I saw he was super on point. Disregard, features I need are missing and that’s the core point. ↩︎