-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration issues from 1.14.4 to 1.15.0 on task table #16828
Comments
Although most of the warnings
This one is not. There should not be a There is no code that would have added this so I don't know how it could be there. 2 options:
|
Or you can just drop column |
I think my issue might be related. I had one failed migration attempt. After rolling back I attempted it again, and received this:
I stopped Gitea and inspected the database... The gitea.tasks table looked like this:
Hence I removed the "ghost"-column, as suggested:
... and started Gitea again. The migrations continued and Gitea started back up with 1.15.0. My "500 issue" from #16725 came back into action however. I hope I do everyone a favor by using a Pastebin for the trace-log instead of extending this already long comment: |
Migration appears successful however I still notice a few quirks that still exist: |
I just attempted the upgrade again with v1.15.2. Out of the box, similar errors about the column
I again applied the "patch" from my last comment. It again allowed the database migrations to finish running, but this time did not cause any 500 errors. Since it seems to be working this way, I will not downgrade again, but can someone confirm if this "patch"ed database is fine to be used, or if there is something possible trying to use this |
It's fine. The message field shouldn't have been present in the task table in the first place. I'm not sure how it got there - did you run a dev version on this db at some point? The Errors field in that task table has now been renamed to message and everything will work fine from now on. Similarly the primary key problem coming back doesn't make any sense at all. Did you migrate using 1.15.0 and 1.15.2? You should just migrate using version 1.15.2 - once we release 1.15.y you shouldn't use 1.15.x where x<y. If you use 1.15.0 you're not going to get any of the fixes we make to migrations in say 1.15.6. You're fine though. Just run the doctor recreate-table command for the issue_index primary key problem and you're done. But for anyone else watching:
If you are on 1.14.3-1.14.6 because there was a bug in the dump command in these versions: if you backup your db using dump then you need to migrate to 1.14.7 to get a dump before you upgrade to 1.15 - but even then do not do 1.14.3,1.14.4,1.14.5,1.14.6,1.14.7 just go straight to 1.14.7 - make the dump and thence straight to 1.15.2. So what do you do if you are on 1.13.x or lower? Backup your db and go straight to 1.15.2 (or 1.15.x where X is the largest point release). That's it. Read the breaking notes for 1.14.0 and 1.15.0 on the blog though. You can if you prefer go via 1.14.7 but you don't need to and from 1.15.3 that's a dead branch. Do not go via 1.14.0 etc - because if you do that you are needlessly exposing yourself to any bugs in migrations in 1.14.0 (which IIRC there were). You get one shot at each migration. We will mitigate bugs in migrations but better will fix them in the code so future users don't experience them. By going via out of date point releases you are needlessly exposing yourself to old bugs in these and preventing us from fixing things. |
Just wanted to mention, after correcting the table schema as suggested, I still experienced small issues such as in-code review not being viewable by others. As a result, I ended up having to export all repos, start from scratch with a stable version of gitea, recreate/reconfigure all orgs and settings, reimport all repos, recreate all users/permissions, and reconfigure all repos. We lost all of our pr history but now we are confident in our foundations on a stable Gitea environment rather than the one that started as a dev build and things are working much more reliably. I’ll be much more careful whether Docker latest is considered dev or stable in the future for other software. Also thanks for your great efforts @zeripath to help us through these partial migrations and hopefully your recent code fix reduces the chance of users falling through the cracks like we did. |
Unfortunately, I mistakenly deployed my team's instance of Gitea using the 'latest' tag of the official Gitea docker image around 3-4 months ago (I believe it was around version 1.14.2 at that time) thinking it was the latest stable release rather than an unstable dev version. I upgraded to the stable gitea/gitea:1.14.4 about 2 months ago. It required me to force migrate the underlying sqlite db in order for it to take. My hope was that some of the extra fields it added, but didn't use yet, would simply be used properly upon upgrade to the next release version. Yesterday I backed up my volume and attempted to upgrade to 1.15.0 but it failed during db migration.
What is the simplest way to ensure I'm back to the correct db schema version? Should I just blast away the volume, start with a fresh install, re-configure, and re-push all local repos to the new installation?
[x]
):The text was updated successfully, but these errors were encountered: