[SOLVED] Upgrade gitea 1.6 to 1.7 problem

As I said in my original post, it’s about regular builds (archlinux repo in my case) and it starts with the upgrade from version 1.6 to 1.7. It affects upgrades, it seems it doesn’t affect fresh installs, so it’s very likely something regarding the DB scheme, probably some “migration” scripts missing. It’s not about the database used, since the problem affects both PostgreSQL and MariaDB based instances and probably SQLite too.
When I find some time, I’ll test also, if the problem persists with the gitea build based on current github code, but i suspect it does. It would be probably useful to test the 1.7 release candidate to establish, if the problem was already there, but I doubt I’ll be able to do it in the next few months since I’m quite busy in this period.

I agree, its the DB schema.

I have solved my problem by (migrate from Sqlite to MariaDB):

  • gitea dump (gitea dump) (with old gitea in my case: 1.5.0)
  • open sql file (sqlite file) and remove all CREATE ( in vim :g/CREATE/d )
  • save your app.ini file (mv app.ini app.ini.org)
  • stop gitea with systemctl
  • start gitea 1.7.2 and install with MariaDB database backend
  • import your sql file (made with gitea dump and edit with vim so only your INSERT queries) on your mairadb gitea db
  • place your app.ini.org back to app.ini
  • start gitea with systemctl
  • done, you have Gitea 1.7.2 with mariadb working + your data.

Maybe its also possible to migrate back to Sqlite but Mariadb is okey for us.

I currently have the same problem.
Gitea inside a docker + sqlite.
I encounter the same error.
Here is the complete startup log from latest docker build (gitea/gitea:latest)

2019/03/04 14:45:37 [T] AppPath: /app/gitea/gitea,
2019/03/04 14:45:37 [T] AppWorkPath: /app/gitea,
2019/03/04 14:45:37 [T] Custom path: /data/gitea,
2019/03/04 14:45:37 [T] Log path: /data/gitea/log,
2019/03/04 14:45:37 [I] Gitea v8e202e2 built with go1.11.5 : bindata, sqlite, sqlite_unlock_notify,
2019/03/04 14:45:37 [I] Log Mode: Console(Info),
2019/03/04 14:45:37 [I] XORM Log Mode: Console(Info),
2019/03/04 14:45:37 [I] Cache Service Enabled,
2019/03/04 14:45:37 [I] Session Service Enabled,
2019/03/04 14:45:37 [I] Beginning ORM engine initialization.,
2019/03/04 14:45:37 [I] ORM engine initialization attempt #1/10...,
2019/03/04 14:45:37 [I] PING DATABASE sqlite3,
2019/03/04 14:45:37 [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? []interface {}{"version"},
2019/03/04 14:45:37 [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? and ((sql like '%`id`%') or (sql like '%[id]%')) [version],
2019/03/04 14:45:37 [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? and ((sql like '%`version`%') or (sql like '%[version]%')) [version],
2019/03/04 14:45:37 [I] [SQL] SELECT `id`, `version` FROM `version` WHERE `id`=? LIMIT 1 []interface {}{1},
2019/03/04 14:45:37 [I] [SQL] BEGIN TRANSACTION,
2019/03/04 14:45:37 [I] [SQL] SELECT `id`, `repo_id`, `type`, `config`, `created_unix` FROM `repo_unit` WHERE (`type` = ?) []interface {}{3},
2019/03/04 14:45:37 [I] Migration: add pull request rebase with merge commit,
panic: interface conversion: interface {} is float64, not bool,
goroutine 1 [running]:,
code.gitea.io/gitea/models/migrations.addPullRequestRebaseWithMerge(0xc00055f2b0, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/models/migrations/v76.go:44 +0x6e9,
code.gitea.io/gitea/models/migrations.(*migration).Migrate(0xc0005fa0e0, 0xc00055f2b0, 0xc0005f9588, 0x1),
	/go/src/code.gitea.io/gitea/models/migrations/migrations.go:54 +0x34,
code.gitea.io/gitea/models/migrations.Migrate(0xc00055f2b0, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/models/migrations/migrations.go:256 +0x368,
code.gitea.io/gitea/models.NewEngine(0x18c7690, 0x2b, 0xc0005f9698),
	/go/src/code.gitea.io/gitea/models/models.go:289 +0x70,
code.gitea.io/gitea/routers.initDBEngine(0x1854340, 0xc),
	/go/src/code.gitea.io/gitea/routers/init.go:52 +0x29c,
	/go/src/code.gitea.io/gitea/routers/init.go:79 +0x50f,
code.gitea.io/gitea/cmd.runWeb(0xc0000f6640, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/cmd/web.go:121 +0xaa,
code.gitea.io/gitea/vendor/github.com/urfave/cli.HandleAction(0x16369a0, 0x18c7550, 0xc0000f6640, 0xc000153e00, 0x0),
	/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:471 +0xad,
code.gitea.io/gitea/vendor/github.com/urfave/cli.Command.Run(0x18433f5, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x186d7f2, 0x16, 0x0, ...),
	/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/command.go:191 +0x97f,
code.gitea.io/gitea/vendor/github.com/urfave/cli.(*App).Run(0xc0000ae340, 0xc00000c060, 0x2, 0x2, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:241 +0x5a2,
	/go/src/code.gitea.io/gitea/main.go:57 +0x438

During the wait, i’ll stick with version 1.6.
If there is anything I can do to help, please tell me.

I’ll try again with the 1.7.4 version in a week or so (when Archlinux gets it, since I use it on the production Arch server), fingers crossed.

This should be a bug I think.

The issue is still there with the 1.7.4 version - probably there are some pre-migration or post-migration hooks missing. I’ll stick with the 1.6.4 for time being and probably switch to gitlab-ce as a long term solution for my production git repos.

I have reviewed related codes and it’s some strange. Could you help to give some data on table repo_unit to help us track the issue.

Happy to help, but I’m very limited in Go. Just tell me what you need me to do and I’ll do it.

If you have any database knowledge, could you dump repo_unit table to me. That’s should not tell me your private message. You can contact me on discord.

Hey, sysadminmatmoz. Has the reason for this issue been identified yet?

Hello @lunny,
Here are the first few lines of the dump of my table repo_unit. I hope it is enough. In case not, I can send the whole file (~250 lines) to you.

$ sqlite3 gitea.db '.dump repo_unit'
PRAGMA foreign_keys=OFF;
INSERT INTO "repo_unit" VALUES(1,6,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(2,6,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);
INSERT INTO "repo_unit" VALUES(3,6,3,'{"AllowMerge":1,"AllowRebase":1,"AllowSquash":1,"IgnoreWhitespaceConflicts":0}',1491305853);
INSERT INTO "repo_unit" VALUES(5,6,4,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(6,6,5,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(8,7,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(9,7,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);
INSERT INTO "repo_unit" VALUES(10,7,3,'{"AllowMerge":1,"AllowRebase":1,"AllowSquash":1,"IgnoreWhitespaceConflicts":0}',1491305853);
INSERT INTO "repo_unit" VALUES(12,7,4,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(13,7,5,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(15,8,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(16,8,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);
INSERT INTO "repo_unit" VALUES(17,8,3,'{"AllowMerge":1,"AllowRebase":1,"AllowSquash":1,"IgnoreWhitespaceConflicts":0}',1491305853);
INSERT INTO "repo_unit" VALUES(19,8,4,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(20,8,5,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(22,9,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(23,9,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);


INSERT INTO "repo_unit" VALUES(409,52,2,'{"EnableTimetracker":false,"AllowOnlyContributorsToTrackTime":false,"EnableDependencies":false}',1552321984);
INSERT INTO "repo_unit" VALUES(410,52,3,'{"IgnoreWhitespaceConflicts":true,"AllowMerge":true,"AllowRebase":true,"AllowSquash":true}',1552321984);
INSERT INTO "repo_unit" VALUES(416,80,1,NULL,1553707116);
INSERT INTO "repo_unit" VALUES(417,80,2,'{"EnableTimetracker":true,"AllowOnlyContributorsToTrackTime":true,"EnableDependencies":true}',1553707116);
INSERT INTO "repo_unit" VALUES(418,80,3,'{"IgnoreWhitespaceConflicts":false,"AllowMerge":true,"AllowRebase":true,"AllowSquash":true}',1553707116);
INSERT INTO "repo_unit" VALUES(419,80,4,NULL,1553707116);
INSERT INTO "repo_unit" VALUES(420,80,5,NULL,1553707116);
CREATE INDEX `IDX_repo_unit_s` ON `repo_unit` (`repo_id`,`type`);
CREATE INDEX `IDX_repo_unit_created_unix` ON `repo_unit` (`created_unix`);

@Mageti Thanks very much.

It’s quite similar to what my file was like (except it was dumped from postgres), isn’t it lunny? :slight_smile:

I have no clue about the reason of the problem, but I would bet that there’s a new (mandatory) column in the > 1.7 that wasn’t there in the 1.6 (just a wild guess).

To me, the problem seems more like a variable type conversion failing.
And my guess would be on the config field. You can see at the beginning of my dump that empty variables are stored as {}, and at the end of the dump, they are stored ad NULL.
I would also guess that {} values were stored using gitea version<1.6, as I started using gitea several years ago, and that NULL values are stored using gitea version==1.6.
But all that are only guesses.

should be

don’t know why it changed.

Good catch ! :+1:

Unfortunately, I am not sure it can be corrected with a simple SQL query, since it’s a json field inside the SQL row. :frowning:

I don’t know sqlite command off top of my head but in mysql it would be:

UPDATE repo_unit SET config = replace(config, '"AllowMerge":1', '"AllowMerge":true');

And as a sidenote as postgresql has native json operations it would be much easier than using a find and replace such as above.

Here is what I have done on my sqlite database:

UPDATE repo_unit SET config = replace(config, '"AllowMerge":1', '"AllowMerge":true');
UPDATE repo_unit SET config = replace(config, '"AllowRebase":1', '"AllowRebase":true');
UPDATE repo_unit SET config = replace(config, '"AllowSquash":1', '"AllowSquash":true');

just to be sure the other fields do not end up with the same error.

Now, I am able to start gitea in latest version (1.7.x) without error.
Many thanks for the help !


@Mageti this is fantastic news!