gitea
gitea copied to clipboard
go-gitea
This pull request is broken due to missing fork information.
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
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)
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.
this issue still exists in the latest try.gitea.io w/ 1.17 dev, is there any plan to fix it?
@lihanglin are you using the Gitea image provided in Docker? If you do, can you please show the output of
docker --version
@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.
@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:
- noexec mounting of gitea repositories
- on 1.17 or anyone running alpine 3.14+ this will be old docker versions causing seccomp failures.
- 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.
@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.
Could this be related to #18189 ? (I had the similar issue due to a missed breaking change in the configuration.)
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.
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
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
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?
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
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 https://github.com/go-gitea/gitea/pull/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.
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.
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)
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?
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.
Upgrading Docker Engine version from 19 to 20.10.18 fixed the issue for me.
Ah so this is YET another duplicate of: https://github.com/go-gitea/gitea/issues/16428, https://github.com/go-gitea/gitea/pull/16451, https://github.com/go-gitea/gitea/pull/16170, https://github.com/go-gitea/gitea/issues/16464, https://github.com/go-gitea/gitea/issues/16484
See https://github.com/go-gitea/gitea/pull/18050
We put a huge warning in to tell people to upgrade their dockers for 1.17.
The bug could be reproduced when click the update branch by rebase in pull request UI.
The bug could be reproduced when click the
update branch by rebasein pull request UI.
~~AHA!~~
~~That is the information I needed.~~
~~I bet this update is not updating the PR heads~~
Nope that should still be happening and it is doing the correct thing on my test instance.
~~Right... ~~
~~So the problem is likely:~~
https://github.com/go-gitea/gitea/blob/8430f738e296cd82f318744e2a9ddf74be27c353/services/pull/update.go#L68-L74
This ~~does not~~ directly causes an update the head refs which should also be being done as part of the post-receive hook.
~~Now... I don't understand why this defer is there because when the post-receive hook is run then that is when the PR should be updated.~~
~~So either: ~~
~~* This whole defer should be removed.~~ ~~* OR it needs to do the update of the PR heads.~~
Looking a bit closer this should still cause an update of the ref head so I still don't understand and I still cannot reproduce this.
Right we need some logs.
Please add tracing logs for services/pull:
[log]
MODE=..., traceconsole
...
[log.traceconsole]
LEVEL=TRACE
MODE=console
EXPRESSION=services/pull
Then reproduce the issue following a rebase and give me the logs.
That way at least I'll be able to see something.
The bug could be reproduced when click the
update branch by rebasein pull request UI.
I cannot reproduce this.
From my above review this is almost certainly related to issues from docker not running hooks and is a duplicate of the many reports of that issue.
If anyone can reproduce - please give us logs.
The bug could be reproduced when click the
update branch by rebasein pull request UI.I cannot reproduce this.
From my above review this is almost certainly related to issues from docker not running hooks and is a duplicate of the many reports of that issue.
If anyone can reproduce - please give us logs.
It could be reproduced from a Gitea instance which upgraded from v1.15. The PR created in version v1.15, after upgraded, click the button may cause this problem. The gitea instance running with systemd