Migration error: rename repo is_bare to repo is_empty

[kimpenhaus]

• Gitea version (or commit ref): docker: gitea/gitea:latest
• Git version: 2.18.1
• Operating system: Docker
• Database (use [x]):
  • PostgreSQL
  • MySQL (10.3.7-MariaDB)
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

I am running gitea inside docker container: gitea/gitea:latest - so I assume this is the latest version. After the last update with watchtower the container won't come up again. Checking the logfiles:

2019/01/18 09:07:18 [I] Migration: rename repo is_bare to repo is_empty
2019/01/18 09:07:18 [...itea/routers/init.go:61 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: select repositories: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '"repository" RENAME COLUMN "is_bare" TO "is_empty"' at line 1

Not pretty sure but while rename column works for MySQL I think it is not working in MariaDB. change column should work for both DBs.

MySQL Ref

MaraiDB Ref

Working statement looks like:

ALTER TABLE
    `repository`
CHANGE COLUMN
    `is_bare` `is_empty` tinyint(1);

[zeripath]

Sigh. Sorry about this.

[kimpenhaus]

no worries 😄 I am even not pretty sure if MariaDB is one of the supported platforms.

I did manual migration by executing the proper sql statement and setting version to 79. Now it's running again.

[wyattoday]

This also happens on MySQL 8.0 / Percona Server 8.0. Same solution.

[xsteadfastx]

also in sqlite....

[zeripath]

If unfortunately you were hit by the migration bug and starting your gitea failed, please follow the below steps:

• Stop gitea if it's still running
• Change the value of the table version from 79 to 78
• Restart gitea

If your version was not 79 you should just run gitea migrate

[zeripath]

Please reply to ensure that you've managed to successfully restart Gitea

[zeripath]

Hmm... I've just had a similar issue on sqlite migrating from versions back to v1.5.3 . The migration is still wrong.

[zeripath]

@lunny It seems that the problem at least for sqlite is that sess.Sync2 locks the schema which means the drop of the index earlier in the transaction breaks. I'm going to put another PR in for this.

[michelebugio]

I do apologize but my gitea docker instance with sqlite is still down.

I understand I do need to change the value of the version table to 79 manually, but I do not seem to be able to run queries within the docker console. I am sure I am missing something as I've never dealt with sqlite within a docker before, but at this point I would like to make it work.

[kimpenhaus]

Is your sqlite DB mounted into the docker as volume? If so, you could connect from share or use https://sqlitebrowser.org. If not - I would recommend copying the DB to a volume mount point and then use console or UI.

And you need to change version to 78 ;-)