Please implement migration features Gitea -> Gitea as available for Github -> Gitea

[IzzySoft]

This is a follow-up from #7748 (cleaned up):

• Gitea version (or commit ref): 1.9.3
• Git version: 2.1.4
• Operating system: Linux
• 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:

Description

When migrating repositories from Github to Gitea, almost all data is picked up – including issues, release notes etc. Unfortunately, this is not the case when migrating between Gitea instances (e.g. moving a self-hosted repo to Codeberg.org). Could we have the same feature-set for that? Thanks in advance!

[stale]

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.

[IzzySoft]

A comment a day
keeps the stale bot away…

Still relevant 😉

[rakshith-ravi]

@IzzySoft is there any PR that currently addresses this?

[IzzySoft]

@rakshith-ravi no idea, I'm not a Go dev.

[6543]

@IzzySoft is there any PR that currently addresses this?

no - but Its on track ...

[j-be]

Any news? If not, I'd be happy to help and work on a PR.

[lunny]

@j-be Nobody are working on this. Please help to send a PR.

[6543]

🤔 in this case #10895 would be interesting ...

[6543]

@j-be it is worth to have a look at https://gitea.com/gitea/go-sdk
and #9084 to get an idear

[j-be]

@6543 thanks, that should make it a lot easier indeed. For #10895: I could just add a dependency on https://gitea.com/gitea/go-sdk to Gitea itself, right?

I see a point in having the SDK (which seems more like just-a-REST-client to me) outside the main repo. I mean, who would want to depend on all of Gitea just to interact with the API?

What I am still unsure about is how I would implement the "migrate from my own Gitea instance" thingy, which is actually what this issue is about. I think this is closely related to #9096, which seems to be still under discussion.

Anyway, I will try to get at least the cloning from https://gitea.com up and running. We'll see how things have evolved until then.

[6543]

I could just add a dependency on https://gitea.com/gitea/go-sdk to Gitea itself, right?

pleace dont ... it would not be acepted anyway ...

... seems more lieka just a REST client ...

It is

I will try to get at least the cloning from https://gitea.com

this is the best way for now ... I'll have a look at #9096 witch will bring a handling for individual inctances and there we can add gitea too

tanks for your effort - I'll looking forward to your pull :)

[j-be]

@6543 ok, no https://gitea.com/gitea/go-sdk then... What do you think about reusing the structs from modules/structs? I'd like to avoid rewriting the whole API model. But using them a custom client should be implemented in no time.

[jolheiser]

This specific feature doesn't really need to rely on #10895, as that would be more so people can import our API structs into their own hand-rolled libraries/clients.

If I understand correctly, this issue is about being able to migrate a repo from one Gitea to another using the migration UI.

The biggest problem would probably be version compatibility between the instances, but that could be discussed later.
A PR implementing this would need to take a look at the migration interface docs and could also look at the existing code for migrations.

[6543]

@j-be @jolheiser I think for now we can just thread go-sdk just as any other external lib and use it similar to the gitlab client ?

[lunny]

@6543 I think we can add go-sdk as dependency library to do that. Why did you think we shouldn't?

[j-be]

So, I have implemented a first rough draft based on gitlab.go and https://gitea.com/gitea/go-sdk, but I found some properties required in the base structs are missing in the Gite-API. In detail (all structs refer to those in modules/migrations/base:

• Issue.IsLocked
• PullRequest.IsLocked
• ReleaseAsset.ContentType
• Milestone.Created and Milestone.Updated
• Comment.Reactions
  are missing in the API (https://try.gitea.io/api/swagger) as far as I can tell.

I'm also not sure yet on how to handle GetComments(issueNumber int64). I copied over the logic from Gitlab Importer. That thingy has the "Gitea shares ID space between PRs and Issues, Gitlab does not, so we need to shift IDs of PRs in order to avoid collisions". That should not be needed for Gitea, right?

It works quite ok as far as unit test goes. It would be great if someone could provide me a Migrated version of https://gitlab.com/gitea/test_repo on gitea.com and either transfer the ownership to me, or give me an AccessToken for it. I based my unit test on gitlab_test.go, but lacking access I'd need to rebuild that whole repo on gitlab.com, which is a bit cumbersome.

[6543]

@j-be to Comment.Reactions and Issue Reactions also
there is a api for it you have to query it for each on its own sadly
if #9497 will be ready at some point, it would/will be easyer

[j-be]

I pushed my first draft for review and discussion. Please be kind, I'm new to go and I'm still in the phase of fighting syntax, semantics, and compiler.

I also faced some weird behaviour when migrating the test_repo to gitea.com (see #11705).

I'm still missing these:

• [Issue|PullRequest].IsLocked
• ReleaseAsset.ContentType
• Milestone.[Created|Updated]
• Comment.OriginalNumber

I'm having some trouble with:

• CommitIDs in Review are returned as empty-string by the gitea.com API, even though they seem to work in ReviewComment
• DiffHunk is empty for just one ReviewComment, while it works on the other one

and finally I seem to be doing something wrong with SHA in both PullRequest.[Head|Base] - I need to further investigate on that.

[IzzySoft]

Thanks a lot to all who contributed to this! 😃