gitlab migrate mergerequests+issues fail

[6543]

gitea version: v1.13.0 - master

error message: Migrate repository from https://gitlab.com/troyengel/archbuild failed: Error 1062: Duplicate entry '284-2' for key 'UQE_issue_repo_index'

to reporduce:

• create toke at gitlab.com
• migrate https://gitlab.com/troyengel/archbuild with pulls and issues

if you only migrate one of them it works. so the problem is related to the workaround for new pull indexes

[techknowlogick]

This is rather unusual, does that mean Gitlab doesn't maintain that issues and PRs must have unique numbers?

Edit: How would comments that reference an issue that has a a PR with the same ID index?

[rsnyman]

@techknowlogick as far as I can tell, in GitLab issues and merge requests are completely separate, so they can easily have "clashing" IDs because they never share data (different tables in the DB I'm guessing). This is in contrast with GitHub which seems to make PRs and Issues the same thing.

[lunny]

So we may have to change the id

[techknowlogick]

So we may have to change the id

We would need ensure that we modify comments/issues that link to PR use updated ID

[togetherwithasteria]

Reproduced this. Slightly different log but same meaning. Running on Docker with version v1.15.7 with Postgres.

gitea       | 2021/12/15 15:56:58 modules/task/task.go:54:handle() [E] Run task failed: pq: duplicate key value violates unique constraint "UQE_issue_repo_index"

Repository used for this: https://gitlab.com/EchidnaHQ/Echidna

[togetherwithasteria]

So we may have to change the id

We would need ensure that we modify comments/issues that link to PR use updated ID

Don't forget about MR and issue references in Git commits. Of course we can't change them, because it will cause the commit to lose its original hash and and thus making commit references in other commits problematic and it will unsign the signed commits, which is not nice because that's the only way to verify that a commit actually came from its author and not people spoofing the git author email and username.

We will have to somehow keep references to the original GitLab issue or MR's ID and make a link for any references to them in Git commits. Perhaps display the original ID as well in the MR/issue page so that noone get confused.

[togetherwithasteria]

Reproduced on Docker running version v1.16.0+dev-692-gf58e687a8 with Postgres.

Repository: https://gitlab.com/troyengel/archbuild

gitea     | 2021/12/15 21:11:22 ...ervices/task/task.go:56:handle() [E] Run task failed: pq: duplicate key value violates unique constraint "UQE_issue_repo_index"

[douglasparker]

This is still a major issue when migrating from GitLab. I had to drop all merge requests to avoid this error and successfully import my repositories.

[wetneb]

This issue is fixed in Forgejo 1.21.2+0.

[delvh]

I mean, this isn't forgejo, but yes, if it is fixed there, it most likely will be here too.

[wetneb]

@delvh as far as I am aware, this is not fixed in Gitea yet: I submitted the corresponding pull requests to Forgejo, and I don't think they got cherry-picked by Gitea. So I would keep this issue open.

[hramrach]

Can you link to the fix in forgejo?

Anyway, I suppose if this is to be fixed then

• An arbitrary prefix needs to be configured for # or ! references for the project (eg. 1000000).
• Manage branches in UI #666 would map to Manage branches in UI #666, and !666 to #1000666 with 1000000 prefix configured for !
• All issues and PRs can be converted, and references in commit messages resolved as well.

This could be hardcoded but making it per-project configuration sounds more reasonable.

[wetneb]

The fix is here: https://codeberg.org/forgejo/forgejo/pulls/1790

[lunny]

The fix is here: https://codeberg.org/forgejo/forgejo/pulls/1790

Can you send a PR to Gitea too?

[wxiaoguang]

The fix is here: https://codeberg.org/forgejo/forgejo/pulls/1790

That change doesn't seem ideal. For example, the ? in filename breaks all Windows developers' workspace.

[hramrach]

It's not ideal indeed. It's very explicit about inability to migrate more issues once any PRs are migrated.

In particular mirroring a repository cannot work this way.

Also it is not clear to me how the !1 reference to a PR in the commit message would be resolved with this solution.