[Docker] Database Migration Issue From 1.11.7 To 1.12.0 #5586

New Issue

GiteaMirror · 2025-11-02T06:29:50-06:00

GiteaMirror commented

2025-11-02 06:29:50 -06:00

Originally created by @ghost on GitHub (Jun 19, 2020).

Gitea version (or commit ref): 1.11.7 To 1.12.0
Git version:
Operating system: docker on Ubuntu
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I got the problem that I could not access any repository of an organization at the UI level.
The link was shown in this format "/<repository name>" instead of "<owner>/<repository name>"

This problem has occured when I switched the docker image with tag: 1.11.7 to 1.12.0.

I verified at the database level that the table "repository" the column "owner_name" had the value "null". So I did manually change it to verify if that fix the problem. So did it.

Is that an issue at the automatic database migration?

Screenshots

Originally created by @ghost on GitHub (Jun 19, 2020).   - Gitea version (or commit ref): 1.11.7 To 1.12.0 - Git version: - Operating system: docker on Ubuntu - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description I got the problem that I could not access any repository of an organization at the UI level. The link was shown in this format "/\<repository name\>" instead of "<owner\>/\<repository name\>" This problem has occured when I switched the docker image with tag: 1.11.7 to 1.12.0. I verified at the database level that the table "repository" the column "owner_name" had the value "null". So I did manually change it to verify if that fix the problem. So did it. Is that an issue at the automatic database migration? ## Screenshots

GiteaMirror added the issue/stale label 2025-11-02 06:29:50 -06:00

GiteaMirror closed this issue

2025-11-02 06:29:50 -06:00

GiteaMirror commented

2025-11-02 06:29:51 -06:00

@zeripath commented on GitHub (Jun 20, 2020):

Not sure what's happened here as it appears that migration 120: 6891b90303/models/migrations/v120.go (L11-L20) didn't get run on your data.

That's weird because Gitea should have migrated the data at the startup of the process - it automigrates.

Do you have a copy of your DB before you updated your tag? It might be reasonable to re-run gitea migrate on that DB.

@zeripath commented on GitHub (Jun 20, 2020): Not sure what's happened here as it appears that migration 120: https://github.com/go-gitea/gitea/blob/6891b90303c391f5b7cbb2ff1a259526d927defb/models/migrations/v120.go#L11-L20 didn't get run on your data. That's weird because Gitea should have migrated the data at the startup of the process - it automigrates. Do you have a copy of your DB before you updated your tag? It might be reasonable to re-run gitea migrate on that DB.

GiteaMirror commented

2025-11-02 06:29:51 -06:00

@ghost commented on GitHub (Jun 20, 2020):

I just re-run gitea migrate.
I don't have the copy of my DB before the update.
If I set the owner_name to null then run gitea migrate.
Should the owner_name be updated? I did try, the owner_name remained to null.
Which other informations do you need?

@ghost commented on GitHub (Jun 20, 2020): I just re-run gitea migrate. I don't have the copy of my DB before the update. If I set the owner_name to null then run gitea migrate. Should the owner_name be updated? I did try, the owner_name remained to null. Which other informations do you need?

GiteaMirror commented

2025-11-02 06:29:51 -06:00

@zeripath commented on GitHub (Jun 20, 2020):

For everyone's sanity make backups!

I cannot stress this enough.

There are way too many different situations for us to be able to completely predict when and why something may go wrong. We really try not to break things but you have to help us.

Backup your database now.

Just setting the values of the owner_name to null would not work. Migrations are governed by the value of the version column in the version table, e.g. in MySQL

SELECT version from version;

To force all the migrations to be reattempted you would have to set the version back to 118, e.g. in MySQL

UPDATE version SET version = 118;

You would then restart Gitea and it should force the migrations from 1.11.7 to 1.12.0 to run.

Looking at the migrations for 1.11.7->1.12.0 I believe that forcing another migration this way should work fine however, in general forcibly causing a re-migration could fail and cause data loss.

I suspect that in your case that none of the migrations have run despite the version being updated to 141 but I do not understand how or why that could happen. (Some prior issues seem to indicate that something like this has happened to other docker installs on previous upgrades but none have given any information as to how that happened - possibly it is due to users temporarily trying updated versions of Gitea and so partial updates have occurred?)

@zeripath commented on GitHub (Jun 20, 2020): # For everyone's sanity make backups! I cannot stress this enough. There are way too many different situations for us to be able to completely predict when and why something may go wrong. We really try not to break things but you have to help us. # Backup your database now. Just setting the values of the owner_name to null would not work. Migrations are governed by the value of the version column in the version table, e.g. in MySQL ```sql SELECT version from version; ``` To force all the migrations to be reattempted you would have to set the version back to `118`, e.g. in MySQL ```sql UPDATE version SET version = 118; ``` You would then restart Gitea and it should force the migrations from 1.11.7 to 1.12.0 to run. Looking at the migrations for 1.11.7->1.12.0 I believe that forcing another migration this way should work fine however, in general forcibly causing a re-migration could fail and cause data loss. --- I suspect that in your case that none of the migrations have run despite the version being updated to 141 but I do not understand how or why that could happen. (Some prior issues seem to indicate that something like this has happened to other docker installs on previous upgrades but none have given any information as to how that happened - possibly it is due to users temporarily trying updated versions of Gitea and so partial updates have occurred?)

GiteaMirror commented

2025-11-02 06:29:51 -06:00

@ghost commented on GitHub (Jul 14, 2020):

I make now backups.
I used the command "gitea doctor" after changing the config file.
Error: migrate: Database has not been initialised
I read the file "doctor.log". It was written the following line:
SELECT id, version FROM version WHERE id=? LIMIT 1 [1] - 1.248029ms
At this table, there wasn't any ids, which had the value 1.
Could this be the problem?

@ghost commented on GitHub (Jul 14, 2020): I make now backups. I used the command "gitea doctor" after changing the config file. Error: migrate: Database has not been initialised I read the file "doctor.log". It was written the following line: SELECT `id`, `version` FROM `version` WHERE `id`=? LIMIT 1 [1] - 1.248029ms At this table, there wasn't any ids, which had the value 1. Could this be the problem?

GiteaMirror commented

2025-11-02 06:29:51 -06:00

@anbraten commented on GitHub (Jul 26, 2020):

Same error happened to me. After upgrading to from docker version 1.12.1. I tried going back down to 1.11.0 and all the way back up from 1.11.1, 1.11.2, ..., to 1.12.0 again but without any success.

My migration version is 141 with id 214.

For now I fixed this for me by manually running: UPDATE repository SET owner_name = (SELECT name FROM `user` WHERE `user`.id = repository.owner_id)

How can I run migrate / doctor command inside my docker container? I only get

# docker-compose exec gitea gitea migrate
2020/07/26 09:07:20 ...s/setting/setting.go:910:NewContext() [F] Expect user 'git' but current user is: root

@anbraten commented on GitHub (Jul 26, 2020): Same error happened to me. After upgrading to from docker version `1.12.1`. I tried going back down to `1.11.0` and all the way back up from `1.11.1`, `1.11.2`, ..., to `1.12.0` again but without any success. My migration version is `141` with id `214`. For now I fixed this for me by manually running: ``UPDATE repository SET owner_name = (SELECT name FROM `user` WHERE `user`.id = repository.owner_id)`` How can I run `migrate` / `doctor` command inside my docker container? I only get ```bash # docker-compose exec gitea gitea migrate 2020/07/26 09:07:20 ...s/setting/setting.go:910:NewContext() [F] Expect user 'git' but current user is: root ```

GiteaMirror commented

2025-11-02 06:29:51 -06:00

@ghost commented on GitHub (Jul 26, 2020):

@anbraten you could use the su command to switch user like su git. You can use then gitea commands.
I did clean the versions table to have only one entry with id 1. That seems to have helped to solved the problem.
After cleaning the versions table, you could too restart the container to run the migrations.

@zeripath does the gitea instance at initialization does INSERT INTO version(version) VALUES (?); ? That could break the migrations if the migrations depends of the id. The first ID is not always 1.

@ghost commented on GitHub (Jul 26, 2020): @anbraten you could use the su command to switch user like `su git`. You can use then gitea commands. I did clean the versions table to have only one entry with id 1. That seems to have helped to solved the problem. After cleaning the versions table, you could too restart the container to run the migrations. @zeripath does the gitea instance at initialization does `INSERT INTO version(version) VALUES (?);` ? That could break the migrations if the migrations depends of the id. The first ID is not always 1.

GiteaMirror commented

2025-11-02 06:29:52 -06:00

@stale[bot] commented on GitHub (Oct 4, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Oct 4, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror referenced this issue

2025-11-02 16:16:34 -06:00

[PR #5586] [MERGED] drone/mssql: use golang 1.11 #17855

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#5586