Gitea: Migration error: rename repo is_bare to repo is_empty

Created on 18 Jan 2019  路  10Comments  路  Source: go-gitea/gitea

  • Gitea version (or commit ref): docker: gitea/gitea:latest
  • Git version: 2.18.1
  • Operating system: Docker
  • Database (use [x]):

    • [ ] PostgreSQL

    • [x] MySQL (10.3.7-MariaDB)

    • [ ] MSSQL

    • [ ] SQLite

  • Can you reproduce the bug at https://try.gitea.io:

    • [ ] Yes (provide example URL)

    • [ ] No

    • [x] 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
bildschirmfoto 2019-01-18 um 10 31 26

MaraiDB Ref
bildschirmfoto 2019-01-18 um 10 32 14

Working statement looks like:

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

Most helpful comment

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 ;-)

All 10 comments

Sigh. Sorry about this.

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.

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

also in sqlite....

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

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

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

@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.

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.

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 ;-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kifirkin picture kifirkin  路  3Comments

BRMateus2 picture BRMateus2  路  3Comments

lunny picture lunny  路  3Comments

jorise7 picture jorise7  路  3Comments

internalfx picture internalfx  路  3Comments