-
-
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 issue: PRs broken after upgrade to 1.17.0 #20826
Comments
You have to manually insert some record into |
What do I need to insert, exactly? |
OK thanks to some help from the gitea discord I figured out the root cause of this problem. 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 |
should be fixed by #20839 |
We are running 1.17.1 already and the issue still persists. |
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. |
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. |
We just ran into this issue on dev.tt-rss.org. Asking people to enable PRs for their fork so that filing a PR against master repo wouldn't crash gitea with a 500 error seems incredibly strange to me. Another strange thing is that PR was rendered properly until I logged in to review it, which is when everything just broke. Hoping for a proper fix. |
Do you have any logs? |
Sure, here's some container logs:
I thought the DB was broken somehow but then I found this issue and asked the contributor to enable PRs on his repo, he did, which stopped the crashes. edit: no stacktrace or anything in logs, just a few more repeats of above lines. |
@cthu1hoo if I'm not mistaken, did you switch your install from gogs? |
Same here, the install has always been native Gitea... If a fork doesn't allow PRs, you cannot view PRs submitted for the parent repository. |
yes, you're right. I did switch from gogs, a while ago. |
Go to the base repository, then go to settings, then click on Enable Repository Pull Requests. |
I wonder if you were affected by #16961? |
already enabled. |
I encounter the same issue with Gitea 1.17.3:
Enabling pull requests on the fork or enabling branch protection on the source branch of the merge request allows to workaround the issue. The logs:
The database content (270 is the id of the repository created in July 2021, 785 is the fork):
The |
Looks like something(unit 2, 3, 5, 8) missed for forked repository. |
…ed (go-gitea#22512) Swallow error just like in go-gitea#20839, for the case where there is no protected branch. Fixes go-gitea#20826 for me, though I can't tell if this now covers all cases.
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:
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
The text was updated successfully, but these errors were encountered: