gitea: Unable to access repos after going from 1.15.0 => 1.15.2

MySQL is not the only database Gitea supports. For a workaround for your situation, regenerated repo_unit table should fix all the problems. Could you show some records of your repo_unit?

MariaDB [gitea]> select * from repo_unit limit 10;
+----+---------+------+----------------------------------------------------------------------------------------------------------------+--------------+
| id | repo_id | type | config                                                                                                         | created_unix |
+----+---------+------+----------------------------------------------------------------------------------------------------------------+--------------+
|  1 |       1 |    1 | &{}                                                                                                            |   1596995039 |
|  2 |       1 |    2 | &{%!s(bool=true) %!s(bool=true) %!s(bool=true)}                                                                |   1596995039 |
|  3 |       1 |    3 | &{%!s(bool=false) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=false) %!s(bool=false)} |   1596995039 |
|  4 |       1 |    4 | &{}                                                                                                            |   1596995039 |
|  5 |       1 |    5 | &{}                                                                                                            |   1596995039 |
|  6 |       2 |    1 | &{}                                                                                                            |   1596995842 |
|  7 |       2 |    2 | &{%!s(bool=true) %!s(bool=true) %!s(bool=true)}                                                                |   1596995842 |
|  8 |       2 |    3 | &{%!s(bool=false) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=false) %!s(bool=false)} |   1596995842 |
|  9 |       2 |    4 | &{}                                                                                                            |   1596995842 |
| 10 |       2 |    5 | &{}                                                                                                            |   1596995842 |
+----+---------+------+----------------------------------------------------------------------------------------------------------------+--------------+
10 rows in set (0.000 sec)

A simple work around is to run UPDATE repo_unit set config = "{}", but you will lose some special settings of repository, you can change the setting again in repository settings page. WARN: Please back up the table before you executed above SQL.

I’ve spent this evening attempting to write a doctor command that would be able to fix these issues.

It’s a substantial amount of work - and although it should fix the repo_units issue the login_sources also need to be fixed - Those are a substantially more difficult proposition.

I’ve pushed up a backport of it to 1.15.

---

People suffering this issue - Please could you take a backup of the repo_unit table, build the PR (backport if you’re on 1.15) and then run the doctor command gitea doctor --fix --run fix-broken-repo-units and report if this solves your issue.

If you require builds of PRs you should contact me or another developer on discord.

@echodreamz when we looked at this together both with your db and me looking at the code we found the following options for config field in the repo_unit table:

Type 6 - External Wiki Configuration

The broken form looks like:

&{url}

but should be:

{"ExternalWikiURL":"url"}

Type 7 - External Tracker Configuration

The broken form looks like:

&{a b c}

But should be:

{"ExternalTrackerURL":"a","ExternalTrackerFormat":"b","ExternalTrackerStyle":"c"}

The problem will be if there are spaces in this one.

Type 3 - Pull Request Configuration

The broken form has two types 1.14:

&{%!s(bool=false) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=false) %!s(bool=false) }

and 1.15:

&{%!s(bool=false) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=true) %!s(bool=false) %!s(bool=false) %!s(bool=false) merge}

But should be:

{"IgnoreWhitespaceConflicts":false,"AllowMerge":false,"AllowRebase":false,"AllowRebaseMerge":false,"AllowSquash":false,"AllowManualMerge":false,"AutodetectManualMerge":false,"DefaultDeleteBranchAfterMerge":false,"DefaultMergeStyle":""}

Type 2 - Issue Configuration

Broken looks like:

&{%!s(bool=true) %!s(bool=true) %!s(bool=true)}

But should be:

{"EnableTimetracker":true,"AllowOnlyContributorsToTrackTime":true,"EnableDependencies":true}

Others

&{}

Should just be

{}

---

The related code is:

https://github.com/go-gitea/gitea/blob/63d7cbcef13b4eb719a5749a1a79361461c77135/models/repo.go#L399-L431

I’m saying there was a serious regression in 1.14.3-1.14.6 that meant the dumps were broken for these two columns but no one noticed. Certainly having spent so damned long making sure that they worked in the first place I didn’t expect that they would suffer a regression like that.

I’ve fixed that regression and added a test to stop it from happening again, however we clearly need to add a stronger testsuite to the dumping behaviour as this test only covers a very small component.

I’m glad that your repo_units config column appeared so easily fixable but I’m surprised it was empty. Have you been consistently restoring from backups? My suspicion is you’ve lost some configuration data here. We need to check your older backups - please contact me on discord or on matrix.

It may not be coming across but I’m seriously and very deeply sorry and annoyed about this. It’s just not good enough that this has happened. If we’re gonna supply a dump command it should bloody well work.