Skip to content
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

Error 500 when trying to create some pull requests in Gitea 1.12.5+ #13597

Closed
2 of 6 tasks
parnic-sks opened this issue Nov 17, 2020 · 8 comments
Closed
2 of 6 tasks

Error 500 when trying to create some pull requests in Gitea 1.12.5+ #13597

parnic-sks opened this issue Nov 17, 2020 · 8 comments
Labels
type/question Issue needs no code to be fixed, only a description on how to fix it yourself.

Comments

@parnic-sks
Copy link

Description

Frequently, when creating a PR on any release higher than 1.12.4, we receive an error 500 followed by exit status 1 and a long, repeating set of logs

batch request: missing protocol: ""

Creating the same PR from the same branch on Gitea 1.12.4 works fine. 1.12.5 and 1.12.6 both have this problem 100% for certain branches. Other branches can create PRs without issue. I have not been able to identify the difference that causes some branches to work and others not. We use submodules and LFS, but there doesn't seem to be a common thread between successes and failures.

Screenshots

When creating the PR:

image

When viewing the PR (one does get created and sends notifications to watchers, but it's empty):
image

@lunny
Copy link
Member

lunny commented Nov 17, 2020

It's related with git-lfs

@parnic-sks
Copy link
Author

parnic-sks commented Nov 17, 2020

Thanks, @lunny ! Is that the case even if this PR/branch had no LFS-controlled files in the set of changes? Also note that it works fine in Gitea 1.12.4.

@lunny lunny added the type/bug label Nov 22, 2020
@lunny lunny added this to the 1.12.7 milestone Nov 22, 2020
@zeripath
Copy link
Contributor

@parnic-sks Sorry this has taken me so long to notice this.

It's clear from your logs that your server is running on Windows.

The error is coming from:

if err := git.Push(headRepoPath, git.PushOptions{
		Remote: baseRepoPath,
		Branch: pr.HeadBranch + ":" + gitRefName,
		Force:  true,
		// Use InternalPushingEnvironment here because we know that pre-receive and post-receive do not run on a refs/pulls/...
		Env: models.InternalPushingEnvironment(pr.Issue.Poster, pr.BaseRepo),
	}); err != nil {

This is essentially calling:

# bashish code
cd $headRepoPath
git push -- $headRepoPath  $prHeadBranch":"$gitRefName

My guess is that the headRepoPath which comes from filepath.Join(filepath.Join(setting.RepoRootPath, strings.ToLower(userName)), strings.ToLower(repoName)+".git") doesn't look reasonable to git.

Now setting.RepoRootPath comes from:

	RepoRootPath = sec.Key("ROOT").MustString(path.Join(homeDir, "gitea-repositories"))
	forcePathSeparator(RepoRootPath)
	if !filepath.IsAbs(RepoRootPath) {
		RepoRootPath = filepath.Join(AppWorkPath, RepoRootPath)
	} else {
		RepoRootPath = filepath.Clean(RepoRootPath)
	}

From your logs it looks like that that is set to d:\gitea\data\repositories\ ?

So that leaves a few questions:

  • Does changing the ROOT to use forward-slashes make it work?
  • Which type of git are you using?
  • Would you be able to replicate the command on a command line to work out how it would need to be changed to make it work?

@parnic-sks
Copy link
Author

Worked through this with @zeripath on Discord and the issue was identified as an LFS problem, just as @lunny thought. The repo in question had several hooks installed, specifically a pre-push hook, that was causing LFS to try and upload if there were LFS-controlled file changes between the source and target branch.

The local fix we came up with was to delete the pre-push hook as well as any other hooks in the gitea repo that were calling out to LFS to do anything. It's unclear how these hooks got there in the first place, so there's probably some user error involved. It would be nice if Gitea could present this info to the user in some way, but for now this fix gets us unstuck.

@zeripath also identified #12839 as the likely cause of this being the reason it appears in 1.12.5 and not 1.12.4 since the clone would not have brought the hooks over, thereby bypassing the issue.

Thanks a ton to @zeripath for helping me through this on Discord and @lunny for the original quick diagnosis!

@zeripath
Copy link
Contributor

I'm gonna close this as repositories created by Gitea should not have git LFS hooks installed. Hopefully your comment above should be enough to fit anyone else who experienced this in future to work out how to fix.

@lunny lunny removed this from the 1.12.7 milestone Nov 25, 2020
@lunny lunny added type/question Issue needs no code to be fixed, only a description on how to fix it yourself. and removed type/bug labels Nov 25, 2020
@NepPure
Copy link

NepPure commented Dec 16, 2020

I'm gonna close this as repositories created by Gitea should not have git LFS hooks installed. Hopefully your comment above should be enough to fit anyone else who experienced this in future to work out how to fix.

@zeripath

I removed hooks/pre.push, everything seems ok.

But I still wonder, what is the correct way to use LFS in Gitea?

@zeripath
Copy link
Contributor

Gitea is its own lfs server. As a client you just use LFS as normal - but Gitea's own copy of the repositories must not have LFS hooks installed.

@NepPure
Copy link

NepPure commented Dec 17, 2020

Gitea is its own lfs server. As a client you just use LFS as normal - but Gitea's own copy of the repositories must not have LFS hooks installed.

Thank you very much, I understand.

@go-gitea go-gitea locked and limited conversation to collaborators Jan 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/question Issue needs no code to be fixed, only a description on how to fix it yourself.
Projects
None yet
Development

No branches or pull requests

4 participants