search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.6k stars 5.45k forks source link

link to create PR after push is missing after update from 1.8 to 1.9 on existing repos #8013

Closed morph027 closed 4 years ago

morph027 commented 5 years ago

This is the server side log when pushing a branch:

Aug 28 09:18:48 gitea gitea[12311]: 2019/08/28 09:18:48 modules/ssh/ssh.go:181:func1() [E] SearchPublicKeyByContent: public key does not exist [id: 0]
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack 200 OK in 46.200043ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 200 OK in 15.310619ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo 200 OK in 166.081004ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started POST /api/internal/ssh/23/update/60351 for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed POST /api/internal/ssh/23/update/60351 200 OK in 21.996506ms

My local shell just gives:

git push --set-upstream origin foo
Total 0 (delta 0), reused 0 (delta 0)
To ssh://git.example.com:2222/repo/test-testproject.git
 * [new branch]      foo -> foo
Branch 'foo' set up to track remote branch 'foo' from 'origin'.

Description

Today i've managed to update Gitea from 1.8.2 to 1.9.2 and after pushing a new branch, i'm missing the remote message to create a new PR introduced in #4716

morph027 commented 5 years ago

Created a new org repo, forked into my user and pushed a branch and the beloved magic link is there...will check the repo hook settings...

morph027 commented 5 years ago

When deleting a fork of a non-working repo and creating a new fork, the link also appears after pushing a new branch.

lafriks commented 5 years ago

From admin settings run Resynchronize pre-receive, update and post-receive hooks of all repositories. task: image

morph027 commented 5 years ago

Nothing changed. Looking at the filesystem, all projects got the same hooks (the initial bash script which loops over all hooks in .d directory and the gitea hook call in .d directory).

Not sure where the hook gets lost. Will try to enable more debug output and see, if i can find something related.

morph027 commented 5 years ago

Also weird, we still got repos which are working without re-fork (in another organisation).

morph027 commented 5 years ago

comparing a fresh fork (user1, where it's working) against a non-working fork (user2):

gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/ user2/repo.git/hooks/post-receive.d/gitea 
gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/gitea user2/repo.git/hooks/post-receive.d/gitea

No difference.

guillep2k commented 5 years ago

Perhaps some users are using VS2019? In my VS2019 I'm not getting the remote messages in the Source Control - Git log, but I do get them if I use git from bash.

morph027 commented 5 years ago

Nayh, just using command line ;)

lunny commented 5 years ago

@guillep2k the push link is more efficient than VS2019 I think. You can just click that link and create a PR in seconds.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

zeripath commented 4 years ago

@morph027 are you sure that the hooks are even running? If your SSH key isn't managed by Gitea i.e. you can log in to the server to a shell then the hooks won't run because the environment won't get set because gitea serv won't get run.

As part of 1.11 I might pop a PR on that enforces pushes to Gitea repos have to be done in such a way that the hooks will run properly.

morph027 commented 4 years ago

The SSH key is managed through Gitea Webinterface.

zeripath commented 4 years ago

Yeah sorry just reading your logs - I can see that the hooks are running.

OK, so does your test repository have another branch or is that the first commit - because if it is the first commit and you have no other branches it will get set as the default branch after you push it - hence no pr message.

morph027 commented 4 years ago

This happens on all existing projects which did have the PR message before the update...

zeripath commented 4 years ago

OK let's look at the logic.

The create a PR logic is in the post-receive hook and is determined by gitea hook post-receive here:

https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/cmd/hook.go#L175-L181

I.e the result from the pushing of a branch is res["create"] = true.

That's determined by here:

https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L173-L240

The important parts are:

https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L173

I.e. you're pushing the creation of a branch not deleting it.

https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L185

I.e. the user is allowed to create PRs

https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L204

i.e. the branch being pushed to is not the default branch - this is the problem with your testcase.

https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L221

i.e. There is not already a PR for this branch

zeripath commented 4 years ago

In 1.8 the logic was determined by:

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L210-L248

The important parts are:

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L210

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L217

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L226

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L237

zeripath commented 4 years ago

The only difference I can see between 1.8 and 1.9 is that your testcase will "work" in 1.8 because 1.8 will not set the default branch to be the first thing that is pushed.

zeripath commented 4 years ago

Are there definitely no errors in your logs? That's the only other way there could be a difference.

morph027 commented 4 years ago

Any logs in particular? Should i set loglevel to trace?

zeripath commented 4 years ago

If you look at the code I've put up above for 1.9, all the points that would cause no output log.Error except for the case that you are pushing to the defaultBranch of a non-fork which doesn't log.

If you are pushing a non-default branch that you should either get a create the branch or visit the branch message. Compare the code between 1.8 and 1.9 I can't see how there could be a difference.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

morph027 commented 4 years ago

Huh, already forgot about ;)

We've upgraded to 1.10.2 recently and the behaviour still exists.

zeripath commented 4 years ago

Maybe it's the determination of isPullRequest allowed? As I wrote above the hook change I don't think can be the cause

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

morph027 commented 4 years ago

Now running 1.11.3, even with PULL_REQUEST_PUSH_MESSAGE = true there's no consistent behaviour. Some forks are working, some not.

zeripath commented 4 years ago

OK can you tell me anything about the cases where this doesn't work? I'm gonna put a guess out here:

Another question are the original forked repos are using an external issue tracker?

morph027 commented 4 years ago

Hi!

Yes, both is true, all of our repos are forks of an organisation upstream and the upstreams are limited. Creating a PR through the webinterface works without problems.

At least in my case, i'm in the owners groups of the orgs.

And there are repos within the same organisation, where everything works.

None of the repos is using an external issue tracker.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

stale[bot] commented 4 years ago

This issue has been automatically closed because of inactivity. You can re-open it if needed.