This pull request is broken due to missing fork information.

[ptman]

Gitea Version

1.16.1

Git Version

whatever is packaged in docker

Operating System

Linux

How are you running Gitea?

Docker

Database

PostgreSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

The PR branch was not up to date, so I tried to update it using rebase on the web UI. This resulted in "This pull request is broken due to missing fork information. "

Screenshots

[lunny]

Yeah, I think there is a bug of update with rebase.

[jolheiser]

This just happened to me over at https://gitea.com/gitea/go-sdk/pulls/580 as well.
Of note, the rebase also removed my GPG signatures. (They are fixed now, but at the time of the update they were gone)

[andre161292]

This is a serious bug in my opinion, as it happens all the time we're updating our PRs by rebasing them. It should be included in the next bugfix- or at least the major 1.17 release.

[FrankCui-FengqiaoCui]

this issue still exists in the latest try.gitea.io w/ 1.17 dev, is there any plan to fix it?

[lihanglin]

I am using the released version 1.16.7 and have the same symptom.

[singuliere]

@lihanglin are you using the Gitea image provided in Docker? If you do, can you please show the output of

docker --version

[lihanglin]

@singuliere
Sorry not to clarify the scenario.
I am using the offical prebuild amd64 gitea image which version is 1,16,7 and deployed native w/o docker.

[zeripath]

@FrankCui-FengqiaoCui - please check your docker version. 1.17 is running alpine > 3.13 #18500 and docker versions less than 20.10.6 will break with hooks not running.

@lihanglin - I need to know more about your situation.

---

I would guess that in all of these cases hooks are not running.

If that is the case the PR head ref will not be being updated at the time of updates to the PR branch head.

You can check this, and the simplest way to do this would be to go to a repository that is affected and look at /graph

Look at the head branch of PR and where the associated label of the PR is e.g. https://try.gitea.io/arandomer/pathological/pulls/25 has the head branch be-broken

So the commit graph would be:

https://try.gitea.io/arandomer/pathological/graph?branch=refs%2Fheads%2Fbe-broken&branch=refs%2Fpull%2F25%2Fhead

and you can see that these are at the same position. (as they should be.)

---

If you have the heads at different places then my first suspicion is that you don't have hooks running and we need to go back down the rabbit hole of looking at that. The biggest causes for this are:

1. noexec mounting of gitea repositories
2. on 1.17 or anyone running alpine 3.14+ this will be old docker versions causing seccomp failures.
3. previously people had problems with strict permissions on systemd on arch.

If the heads are the same - well then we're gonna need logs, a reproducing testcase, and more information than "this is a serious bug" etc.

[lihanglin]

@zeripath
Thanks for your response.
I will get more dig to know if my hook went wrong.
If I have more clue, I would share with you all.

[penguineer]

Could this be related to #18189 ?
(I had the similar issue due to a missed breaking change in the configuration.)

[amvasilyev]

Hello. We have stumbled upon this issue after migrating to 1.17.0. We have been using 1.16.8 before that and there was no such error.

Any PR that is opened in Gitea is moving to the state 'This pull request is broken due to missing fork information.' after the new commits are added to the tracking branch.

This may be related with the fact that new commits are no longer displayed in the feed on the starting screen.

Docker version 19.03.2, build 6a30dfca03
gitea/gitea 1.17.0 71d4bdcd6398 11 days ago 247MB

Currently the host machine is Debian Stretch and I am currently stuck with 19.03 engine.

[amvasilyev]

I think that the issue is definitely in heads not being updated. I got to the testing repository:

# git show-ref
7c6241b4e54d5ef80ebf0d855466d300a07aa59e refs/heads/master
0093d051c30d314cd850ecb4c5941c9ce29aadc6 refs/heads/pr-test
da0b31358e8e7aab1da9a8a9ea77232d1436884c refs/pull/1/head

The gitea is storing data directly on the host machine:

    volumes:
      - /srv/gitea/data:/data

[99rgosse]

Hello. We have stumbled upon this issue after migrating to 1.17.0. We have been using 1.16.8 before that and there was no such error.

I could reproduce 👍
I have a production server with Gitea 1.16.8, and a development server which is under v1.17

• I brought the backups from 1.16.8 to 1.17
• Opened a PR that was needing a rebase

2022/08/11 08:46:20 [62f497eb-28] router: slow POST /myrepo/myrepo/pulls/3791/update?style=rebase for 10.0.2.2:59331, elapsed 3107.4ms @ repo/pull.go:805(repo.UpdatePullRequest)
2022/08/11 08:46:22 [62f4a5be] router: completed POST /api/internal/hook/pre-receive/myrepo/myrepo for 127.0.0.1:38792, 200 OK in 16.6ms @ private/hook_pre_receive.go:108(private.HookPreReceive)
2022/08/11 08:46:22 router: completed POST /api/internal/hook/post-receive/myrepo/myrepo for 127.0.0.1:38794, 200 OK in 10.7ms @ private/hook_post_receive.go:28(private.HookPostReceive)

2022/08/11 08:46:23 ...s/repository/push.go:41:handle() [E] pushUpdate failed: gitRepo.GetCommit: object does not exist [id: 6ce324747488fd74bc7c77ee6d5bb0d20f292891, rel_path: ]

2022/08/11 08:46:23 [62f4a5b9] router: completed POST /myrepo/myrepo/pulls/3791/update?style=rebase for 10.0.2.2:59331, 303 See Other in 6404.6ms @ repo/pull.go:805(repo.UpdatePullRequest)
2022/08/11 08:46:24 [62f4a5bf-16] router: completed GET /myrepo/myrepo/pulls/3791 for 10.0.2.2:59331, 200 OK in 251.5ms @ repo/issue.go:1122(repo.ViewIssue)

This pull request is broken due to missing fork information

Now that I can reproduce, I will debug it

[amvasilyev]

In our situation every PR is broken when a new commit is pushed to the tracking branch.

The default policy for broken repositories is to make a rebase when accepting changes from the request.

Is it worth to try to use the binary directly instead of the Docker?

[99rgosse]

In our situation every PR is broken when a new commit is pushed to the tracking branch.

The default policy for broken repositories is to make a rebase when accepting changes from the request.

Is it worth to try to use the binary directly instead of the Docker?

the docker is made from the official binary, this won't change.

Could you please confirm that your PR that are failing came from a fork ? As the bug I was able to reproduce ??
The error message I get is from here https://github.com/go-gitea/gitea/blob/release/v1.17/services/repository/push.go#L164

[amvasilyev]

Could you please confirm that your PR that are failing came from a fork ?

No. For the test purposes I have created a test a brand new repository. The whole commit tree is here:

commit 9f6518bde4cbea0309d5c4de58725e9241ab90c1 (HEAD -> prtest, origin/prtest)
    Add more data

commit e220345deee07ff4d04193429ffef2ea43c98cc7
    Add more info

commit 4a57372e8a391033b315861e72786cf7e61c280c
    Add some commit

commit 11a06d09e017a82e17e192045d2bb1818b01d4ea (origin/main, main)
    first commit

After the first commit, I have created a prtest branch. From that branch the PR to the same repository has been opened. When I have pushed the third commit, the PR moved to the broken state.

After grepping the logs of gitea I do not see the message with the gitRepo.GetCommit message, i.e.:

$ docker container logs gitea | grep GetCommit
$

the docker is made from the official binary, this won't change.

The change would be the removal of the Docker layer. The idea is from this comment:

please check your docker version. 1.17 is running alpine > 3.13 #18500 and docker versions less than 20.10.6 will break with hooks not running.

I also carefully reread the original issue and in my case the issue is not the same, but resulting state is the same.

[amvasilyev]

I have set up the temporary instance of gitea 1.17.0 running inside the docker container. The issue was reproduced in this environment too. Therefore there is minor chance that the issue came alongside with the migration.

Then in this additional installation I have swapped the docker image with the native binary. In this setup the issue is gone. Therefore the source of my issue is the old version of docker runtime.

[99rgosse]

Back to the fork problem I dug up this https://github.com/go-gitea/gitea/blob/release/v1.17/routers/web/repo/pull.go#L563

if pull.HeadRepo == nil || !headBranchExist || headBranchSha != sha { ctx.Data["IsPullRequestBroken"] = true

Conditions I have is that headBranchSha != sha because the fork was made with signed commits

"Updating by rebase" will then rebase the commits on top of master, but as it is a Gitea commits side operation, commits are not signed anymore, thus they have not the same SHA.

@lunny / @zeripath I would like to help work on a PR for this issue, could you please tell me your opinion ?
I have not yet figured out how to check this behavior. Maybe with a git diff between unsigned & signed, then accept that the SHA are different, even if not signed ?
Or completely remove possibility to do this from gitea side when you have signed commits ? (Github does not do this rebasing feature I think)

[andre161292]

Any update on this? It's not working for me as well with Docker version 20.10.18 and Gitea 1.17.2.

Can i help out with any more information or logs?

[99rgosse]

I worked out the way to update the fork without broking the PR.

Problem is still that the PR gets different commit sha's than the fork, then it fails the merging (security checking the checksums are identical) => I was not able to workaround this (no time)

My first idea would be to flash a message "Gitea cannot rebase on signed commits, please rebase manually your fork" (the Github way to do it)

If we are to allow rebasing by gitea, this would mean gitea should be able to force push to fork to make the checksums corresponds.

[hieptuanle]

Upgrading Docker Engine version from 19 to 20.10.18 fixed the issue for me.

[zeripath]

Ah so this is YET another duplicate of: #16428, #16451, #16170, #16464, #16484

See #18050

We put a huge warning in to tell people to upgrade their dockers for 1.17.

[zeripath]

@99rgosse I don't understand your comment or how it's being reproduced.

[lunny]

The bug could be reproduced when click the update branch by rebase in pull request UI.

[lunny]

related #16125

[zeripath]

hmm... I wonder if this is actually an issue with force-pushes in general. Nope.

I suspect it's a bug in pushUpdates

No it's in the pushing environment!

[Vylpes]

Still getting this error on 1.18.2 when merging in changes because the PR was outdated

[zeripath]

@Vylpes please could you explain how you reproduce the error, because I cannot reproduce on main or on 1.18.2.

[delvh]

Hmm, I just noticed that the fix can only be part of the solution:
The solution works for repos that have forks that send PRs.
I think I've seen this message on PRs in a repo that doesn't have forks.
So, perhaps, there is a part two to this problem?
(However, that was around 1.14 or so, so I don't know if this is still relevant)

[MHOOO]

In my case the repository is definitely not a fork, yet I'm still having this issue delvh ***@***.***> schrieb am Sa., 21. Jan. 2023, 14:33:

…

Hmm, I just noticed that the fix can only be part of the solution: The solution works for repos that have forks that send PRs. I think I've seen this message on PRs in a repo that doesn't have forks. So, perhaps, there is a part two to this problem? — Reply to this email directly, view it on GitHub <#18802 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACIMCHVKL7D6MSZJL457WLWTPQUPANCNFSM5OXEDGAA> . You are receiving this because you commented.Message ID: ***@***.***>

[Vylpes]

@zeripath Pretty much all I did was:

1. have a PR created, update the base branch (making the PR out of date)
2. updating the PR by either the "update branch" button or by pushing to the branch

This is on an organisation repo, no forks, just from a feature/* branch to develop. I've tried PRs that were made before updating and making new PRs

[zeripath]

@Vylpes I cannot reproduce that on 1.18.2 or on try. (see https://try.gitea.io/testOrf/test-18802/pulls/1, https://try.gitea.io/testOrf/test-18802/pulls/2, https://try.gitea.io/testOrf/test-18802/pulls/3, https://try.gitea.io/testOrf/test-18802/pulls/4)

If your PR was broken already it will remain broken - just push an empty commit and it should resync.

[Vylpes]

@zeripath Then I have no clue why my instance is still doing it - I've pushed an empty commit and it doesn't fix it (nor does it show in the commits list in the PR).

Is there anything I can give you other than that to help? Or is there a way I can "reset" my instance without losing repo data?

[zeripath]

It sounds like your hooks aren't running.

How are you pushing? SSH or Https?

What are you running on Linux, windows, docker etc? Are your repos mounted on an executable partition?

Have you resynchronized your hooks?

[Vylpes]

It sounds like your hooks aren't running.

That might actually be it - As drone isn't picking up on anything either which is also webhook related.

How are you pushing? SSH or Https?

Https

What are you running on Linux, windows, docker etc? Are your repos mounted on an executable partition?

Docker running on a Linux host. The repos are in a volume formatted with ext4, which I and all users have execute permissions on.

Have you resynchronized your hooks?

I've clicked on "Resynchronize pre-receive, update and post-receive hooks of all repositories." in the admin dashboard but no fix

[Vylpes]

I think I fixed it, I moved my data into a different partition and its working now. Must have not liked where it was.

Thanks for the support :)

[zeripath]

It was likely mounted noexec

[zekexiao]

After upgrade 1.18.3 still have this issues, should I disable some option like "PR rebase"？

[zeripath]

@alluLinger explain how you make the break happen. Make sure that pushes in general are working - that is your dashboard gets updates when you push.

I need details for how to make the bug occur and information about your system.

I need logs.

I'm not a mind reader.

[zekexiao]

@zeripath
I can't reproduce it on a new repo/new instance.
on my origin repo got a 500 code after I hit create a PR. the logs I need ask our ops, will post it later.

[zekexiao]

log here: log.txt

looks like this error:

gitea/services/pull/pull.go

Line 478 in f6cb786

log.Error("Unable to push PR head for %s#%d (%-v:%s) due to Error: %v", pr.BaseRepo.FullName(), pr.Index, pr.BaseRepo, gitRefName, err)

on Windows Server, gitea version 1.18.3 with sqlite.

[zekexiao]

@lunny @zeripath
I think I fix this by remove ".git/hooks/pre-push" on server. I found our server repo has a empty file "hooks/pre-push" so error: waitpid for (NULL) failed: No child processes.
when commit a PR will pre-push first then the error occured, so finally missing fork information.

#6460

[zeripath]

Ah. We don't use pre-push so something may have put that there that wasn't Gitea. If a broken pre-push was causing this issue then I'm afraid it's not due to Gitea and whilst there is potentially a way we can avoid this - we can't consider this a bug in Gitea.