500 Error On Release Page

[carc1n0gen]

• Gitea version (or commit ref): 1.9.3
• Git version: 2.23.0
• Operating system: Freebsd
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: https://gist.github.com/carc1n0gen/85b5b52130ea7be722eb85da202be158

Description

I created a repo on my gitea instance, added as a remote on an existing repo, and pushed. That was fine. I then noticed the releases page was empty since I hadn't pushed the tags. So I pushed the tags. Now the releases page yields a 500 error page.

The repo is public, so here it is: https://gitea.carsonevans.ca/carson/quickpaste/releases

[lafriks]

Could be that you have pushed tags for branches that are not pushed to repo?

[carc1n0gen]

All of the tags are version tags off of master unless I made a mistake along the way. Is there a way to find out? But I am very confident I've only ever tagged off master

EDIT: I've only ever had maybe 4 temp branches besides master on this repo.

[carc1n0gen]

I think if that were the case, I would have been able to reproduce on the try.gitea.io instance

[carc1n0gen]

If someone wants to take a look at my database I can send it. There's no secret repos in it. I'll scrub the password hashes first (its just me)

[zeripath]

Hmm, those logs are xorm logs. Is there any console output? For a 500 you should have something logged.

Another option is to switch the RUN_MODE from prod to dev in app.ini

In fact that would probably be quite helpful as we should see the trace of the error.

[carc1n0gen]

2019/10/12 16:59:43 ...ters/repo/release.go:115:Releases() [E] calReleaseNumCommitsBehind: GetBranchCommit: object not found

Sounds like I am indeed missing a referenced branch from that error? The problem is this project began on GitHub, and I'm migrating it to gitea. I've pushed the only branch I still have lying around to gitea with no luck. Not sure where to go from here.

[zeripath]

So that's coming from:

gitea/routers/repo/release.go

Lines 36 to 40 in 3249c0c

	if repoCtx.GitRepo.IsBranchExist(release.Target) {
	commit, err := repoCtx.GitRepo.GetBranchCommit(release.Target)
	if err != nil {
	return fmt.Errorf("GetBranchCommit: %v", err)
	}

[zeripath]

And from your logs it looks like it's release id 10

[zeripath]

Now this is odd, because we first of all test is the BranchExists and then when we try to get the commit it fails.

So it's a bit weird. Either one of these is lying to us or the git object db and it's references are broken.

Hmm what to do... I guess it would be nice to find out what the target is - that can be done by interrogating the database.

Then it would be helpful to check the git repository on the server to see if that target is there.

It could be that the tags haven't been pushed completely or some other weirdness.

Another thing is to check those functions above to see if they really are looking at the same thing

[carc1n0gen]

Very early in the project I did rebase master one time. I know thats a no-no, but the project wasn't public yet, and I already had some tagged releases. Would that have this effect? I'll try to take a look at the db and see what release id 10 points at

[carc1n0gen]

This is the release record:

10|10|1|v2.0.4|v2.0.4|||e7e16cf155afc2c77733dd8081cef28612021eca|11||0|0|1548175363|1

I'll take a look at that tag

[zeripath]

It's the target you should be looking at. In your record it appears to be empty.

Not sure why it would be that way though.

[carc1n0gen]

Okay. What data from the tag should be there? Even if we can't figure out why it's missing, I'd like fix it so I can use the releases page. Or maybe I should just remove the record/tag and move on?

[zeripath]

I guess you could just add the tag name as the target? Assuming it's present in the git references. Just double check it's actually empty because if it's not we're going down the wrong route.

I don't know this bit of code at all - I've never actually looked at it. So I literally have no idea how it have gone wrong. Target clearly needs to be a commit reference that git can find.

TBF It's a bit crap that one error in one release causes a 500 - I think this needs a review.

IsBranchExist is probably to blame though here - it shouldn't be returning true if the target is empty or can't be got. So I think I'm gonna look at that first.

[zeripath]

IsBranchExist is:

gitea/modules/git/repo_branch.go

Lines 29 to 33 in 5e759b6

	// IsBranchExist returns true if given branch exists in current repository.
	func (repo *Repository) IsBranchExist(name string) bool {
	_, err := repo.gogitRepo.Reference(plumbing.ReferenceName(BranchPrefix+name), true)
	return err == nil
	}

I suspect this might return true I think if name was empty.

So that's probably a problem.

[zeripath]

gitea/modules/git/repo_commit.go

Lines 147 to 154 in ee11974

	// GetBranchCommit returns the last commit of given branch.
	func (repo *Repository) GetBranchCommit(name string) (*Commit, error) {
	commitID, err := repo.GetBranchCommitID(name)
	if err != nil {
	return nil, err
	}
	return repo.GetCommit(commitID)
	}

gitea/modules/git/repo_commit.go

Lines 37 to 40 in ee11974

	// GetBranchCommitID returns last commit ID string of given branch.
	func (repo *Repository) GetBranchCommitID(name string) (string, error) {
	return repo.GetRefCommitID(BranchPrefix + name)
	}

So if name is empty this would cause your error.

[carc1n0gen]

The target is for sure empty

[zeripath]

If you're able to rebuild Gitea you could try adjusting IsBranchExist to check if name is empty before it does the reference check by adding:

if name == "" {
  return false
}

Appropriately fmt'd of course.

[carc1n0gen]

I'm using the binary package provided from freebsd so I cannot do that.

[carc1n0gen]

So it actually turns out that every release record from that release and onward have an empty target. No idea why that is, and not sure what to do at this point.

Not a single release record has a target and there are 51 of them

[zeripath]

Oks I should just check that this function hasn't changed between 1.10 and 1.9.3

They haven't.

[zeripath]

Where have you got this FreeBSD release? Is it the Darwin release?

[carc1n0gen]

No Darwin is macOS. FreeBSD has it in their package manager, so they're building it themselves. I get updates when installing updates to installed packages and it prints out additional instructions in the case there were changes that require manual intervention, which has happened in the past.

[zeripath]

OK, well that means that I cannot test if my fix works because I can't build it for you.

There's also the potential issue that you're looking at a bug introduced by the FreeBSD port - or some weirdness to do with it.

Looking again at #8485 I can't see why it shouldn't work originally unless that go-git does something on freebsd...

Is there any chance you could check whether the problem exists using the same DB and repos on linux, or can reproduce it on try.gitea.io?

[carc1n0gen]

My original post indicates I was not able to reproduce on try.gitea.io. I'll try to find the proper channels to investigate the freebsd port