[Migration from Gitlab] Incorrect release name leads to full migration failure

[99rgosse]

• Gitea version 1.15.2

• Git version: 2.17.1

• Operating system:
  Ubuntu 18.04
  gitea repo cloned and built with :
  using TAGS="bindata sqlite sqlite_unlock_notify" make build

• Database (use [x]):

  • SQLite

• Can you reproduce the bug at https://try.gitea.io:

  • No (sensible data)

• Log gist:

Debug log :
2021/09/14 10:45:12 modules/task/task.go:54:handle() [E] Run task failed: GetTagCommit[myrelease/0_4]: object does not exist [id: refs/tags/myrelease/0_4, rel_path: ]

Console log :
2021/09/14 15:52:10 ...dules/git/command.go:120:RunInDirTimeoutEnvFullPipelineFunc() [D] /home/local/gitea/data/gitea-repositories/99rgosse/test.git: /usr/bin/git -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= log -1
2021/09/14 15:52:10 ...dules/git/command.go:120:RunInDirTimeoutEnvFullPipelineFunc() [D] /home/local/gitea/data/gitea-repositories/99rgosse/test.git: /usr/bin/git -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= cat-file --batch
2021/09/14 15:52:10 ...dules/git/command.go:120:RunInDirTimeoutEnvFullPipelineFunc() [D] /home/local/gitea/data/gitea-repositories/99rgosse/test.git: /usr/bin/git -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= cat-file --batch-check
2021/09/14 15:52:11 ...dules/git/command.go:120:RunInDirTimeoutEnvFullPipelineFunc() [D] /home/local/gitea/data/gitea-repositories/99rgosse/test.git: /usr/bin/git -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= remote rm origin
2021/09/14 15:52:11 ...dules/git/command.go:120:RunInDirTimeoutEnvFullPipelineFunc() [D] /home/local/gitea/data/gitea-repositories/99rgosse/test.git: /usr/bin/git -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= cat-file --batch
2021/09/14 15:52:11 ...dules/git/command.go:120:RunInDirTimeoutEnvFullPipelineFunc() [D] /home/local/gitea/data/gitea-repositories/99rgosse/test.git: /usr/bin/git -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= cat-file --batch-check

2021/09/14 15:52:11 ...ules/task/migrate.go:68:func1() [E] DeleteRepository: repository does not exist [id: 29, uid: 1, owner_name: , name: ]

2021/09/14 15:52:11 modules/task/task.go:54:handle() [E] Run task failed: GetTagCommit[myrelease/0_4]: object does not exist [id: refs/tags/myrelease/0_4, rel_path: ]2021/09/14 15:52:13 ...s/context/context.go:740:1() [D] Session ID: f61f7159e7a9accf
2021/09/14 15:52:13 ...s/context/context.go:741:1() [D] CSRF Token: 

Description

Unfortunately someone here named his release myrelease/0_4

Even gitlab cannot retrieve this release with curl, while on graphic interface it works well.

In gitea, this means that all the repository import fails due to this misleading name, otherwise I have to import all the repository without release, then remake some of them.
There are absolutely no explanation message, so I was wondering if we should catch this error differently ?
...

[delvh]

Well, to be fair that sounds more like a GitLab than a Gitea problem to me.
It shouldn't be possible to create names that are forbidden, or have your API not ready to handle these cases.

From an algorithmic point of view, I can understand the current approach as it is easy to implement.
While it most likely would be possible to simply ignore invalid issues/ milestones/ releases/ branches/ PRs, it certainly is much more work, and some users might complain about missing things in the end.
Even worse is that this approach then will have to be duplicated for any service where Gitea can migrate from, resulting in even more things to implement.

[99rgosse]

Well, to be fair that sounds more like a GitLab than a Gitea problem to me.
Even worse is that this approach then will have to be duplicated for any service where Gitea can migrate from, resulting in even more things to implement.

Your answer makes totally sense... I was wondering whether it should be handled or not.

From another point of view, if I was to be "testing" gitea for escaping github/gitlab, this would annoy me, because of the lack of explanation in the failure message. Just a warning "gitlab release myrelease/0_4 not accessible" would then "report the fault on the other side".

I will make a Gitlab ticket though, in order to get their answer for their api failure :D

[99rgosse]

Hello
I'm still waiting for Gitlab answer, but trying to reproduce the bug on a non critical data repository, everything went great !
I close the issue, as it's clearly not Gitea problem
https://try.gitea.io/99rgosse/release_fail
Thanks everyone and sorry for having bothered you

[zeripath]

hmm... actually I think it might be a gitea problem:

 2021/09/14 15:52:11 modules/task/task.go:54:handle() [E] Run task failed: GetTagCommit[myrelease/0_4]: object does not exist [id: refs/tags/myrelease/0_4, rel_path: ]2021/09/14 15:52:13 ...s/context/context.go:740:1() [D] Session ID: f61f7159e7a9accf

I'm not certain that should cause the migration to fail completely.

[lunny]

It's a problem similar as #16919

[99rgosse]

hmm... actually I think it might be a gitea problem:

 2021/09/14 15:52:11 modules/task/task.go:54:handle() [E] Run task failed: GetTagCommit[myrelease/0_4]: object does not exist [id: refs/tags/myrelease/0_4, rel_path: ]2021/09/14 15:52:13 ...s/context/context.go:740:1() [D] Session ID: f61f7159e7a9accf

I'm not certain that should cause the migration to fail completely.

I got the final clue : the person responsible for the badly named release deleted the tag myrelease/0_4 then could not change the name of the release...
Using gitlab rails console, I can change the tag to the new one. Gitlab & Gitea migration are now happy...

Otherwise Gitea failed when calling
this upload release function from gitea_uploader.go
but indeed, to avoid failure of full migration, replacing the return fmt.Errorf("GetTagCommit[%v]: %v", rel.TagName, err) with a log.Error
and a continue
does the job, but there is no warning for the end user...