gitea icon indicating copy to clipboard operation
gitea copied to clipboard

Migration issue: PRs broken after upgrade to 1.17.0

Open wolfbeast opened this issue 1 year ago • 8 comments

Description

After upgrading from 1.12.6 to 1.17.0, I'm running into an issue where any mergable PRs result in server error 500s. Merged PRs and WIP PRs display normally.

Relevant log lines:

2022/08/17 10:58:16 ...vices/pull/update.go:109:IsUserAllowedToUpdate() [E] [62fcc9c8] pr.BaseRepo.GetUnit(unit.TypePullRequests): Unit type does not exist: TypePullRequests
2022/08/17 10:58:16 ...ers/web/repo/pull.go:509:PrepareViewPullInfo() [E] [62fcc9c8] IsUserAllowedToUpdate: Unit type does not exist: TypePullRequests

I followed to recommended upgrade procedure (and also removed any custom templates we had in use previously). The upgrade seems to have gone OK otherwise. gitea doctor also doesn't show anything wrong.

If possible, a "quick fix" as a workaround for this error would be appreciated as we're currently unable to perform any merges in gitea which is a showstopper.

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.37.1

Operating System

CentOS Linux 7.9.2009

How are you running Gitea?

From binary downloaded from gitea.io

Database

MySQL

wolfbeast avatar Aug 17 '22 12:08 wolfbeast

You have to manually insert some record into repo_unit table.

lunny avatar Aug 17 '22 13:08 lunny

What do I need to insert, exactly?

wolfbeast avatar Aug 17 '22 13:08 wolfbeast

OK thanks to some help from the gitea discord I figured out the root cause of this problem. The issues is that the migration apparently flipped off "enable pull requests" for the fork the PR was made upstream from. With the fork's setting having PRs off, the PR on the upstream repo throws a 500 in 1.17.0 Going into the fork's setting to enable PRs to the forked repo, it fixes the error on the parent repo.

This is definitely a bug - parent repo PRs should not depend on whether forks have certain settings enabled on them or not, and certainly shouldn't be throwing a server error as a result ;-)

EDIT: See also #20621

wolfbeast avatar Aug 17 '22 14:08 wolfbeast

should be fixed by #20839

lunny avatar Aug 18 '22 01:08 lunny

We are running 1.17.1 already and the issue still persists.

morph027 avatar Aug 25 '22 09:08 morph027

You need to update the repos involved to enable the PullRequests unit

zeripath avatar Sep 04 '22 21:09 zeripath

You need to update the repos involved to enable the PullRequests unit

I would have expected that to occur with the db migration, so there is a potential solution that doesn't involve having to manually have people of every fork go into their repo settings to make this happen and not get stuck on this when they try to make a PR further down the line.

wolfbeast avatar Sep 05 '22 12:09 wolfbeast

You need to update the repos involved to enable the PullRequests unit

Why do the forks need to have "pull requests" enabled when we only want pull requests on the parent? This issue still persists for us with 1.17.1. The only work around is to enable pull requests on the forks the individual PR originates from.

kakra avatar Sep 12 '22 11:09 kakra