Releases don't migrate from Github

[Rory-Anderson]

• Gitea version (or commit ref): 1.1
• Git version: 2.9.3
• Operating system: Ubuntu LTS
• 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

As the title says, when migrating a repository over from Github, it doesn't take any of the information, like title and release notes. It also leaves the attachments. I know that github allows other file types as attachments (I don't know all the types but I use .sql files a fair amount), would this mess it up?

Screenshots

[bkcsoft]

Releases on GitHub isn't tied to the git-repo itself, migrating them would require talking to GitHubs API, which we purposefully don't do. Adding support to do so would lead to people asking about (or sending PRs for) supporting other providers, and there are so many different providers that it would end up as code-bloat. And the fact that there's no way to test this migrations without calling out to all those providers, meaning we'd introduce more untested code.

If you want proof of my claims, have a look at GitLabs migration-code. While nicely done, it is still in my opinion somewhat of a beast 😅 (Side-note: I did most of the Gitea-migrator for GitLab)

[ulm0]

@bkcsoft any plans on being able to add/edit releases notes and stuff?

[bkcsoft]

One should be able to do that already, Releases are not hard-bound to a Tag AFAIK

[h-2]

Releases on GitHub isn't tied to the git-repo itself, migrating them would require talking to GitHubs API, which we purposefully don't do.

It would be super cool if this were to change in the future ❤️

Adding support to do so would lead to people asking about (or sending PRs for) supporting other providers, and there are so many different providers that it would end up as code-bloat.

Just because you do A, doesn't mean you have to do B; there is no reason to treat mult-million-user-base platforms the same as obscure niche-products. And GitHub is the de-facto standard, I mean you are hosting your own code on GitHub instead of an instance of your own code 😉
I think it would really help adoption to make inter-operability with / conversion from GitHub as easy as possible.

[bkcsoft]

@h-2

It would be super cool if this were to change in the future ❤️

Most likely will not 😉

I mean you are hosting your own code on GitHub instead of an instance of your own code

We're only doing that because Gitea is currently missing a few key features (like proper CI integration and code reviews). End goal is self-hosting.

I think it would really help adoption to make inter-operability with / conversion from GitHub as easy as possible.

While I agree with that, I don't agree that this should be part of Gitea itself.

Reasons: (almost exact copy of #1876 (comment))

1. Less code in Gitea makes for less bugs.
2. This is a "niche" thing that most users don't need or ever use.
   Sure, users migrate between services, but they usually only do it once (at least from platform X to platform Y)
3. If it exists for platform X, people will request it for platform Y. Just saying "that platform is not big enough to be considered" is not gonna cut it, hence the feature itself is cut 🙂 Also consider what happens when someone suddenly change their API (like GitLab did in 9.0 going from v3 to v4, though still maintaining v3 for a bit longer), then Gitea would have to be updated, and this would have to be backported since not everyone wants to upgrade their instance (with the downtime and bugs that comes with that). Having this as a separate specific tool would not require users to upgrade, or maintainers to backport, but simply install a separate tool that they can throw away once they're done with it.

[lafriks]

I completely agree with @bkcsoft that there should be created tool to do migrations from different platforms to gitea

[bkcsoft]

@lafriks If written properly, it would be cross direction, so Gitea <=> GitHub <=> GitLab <=> Gitea, etc...

[Governa]

Maybe there could be an API/plugin system to allow for easy migration of every (supported) feature. Maybe only documenting how to create a custom script is enough. Then other people could do it as separate projects. This solves the problem of code bloat.

I use Gitolite/Redmine at work and would love to migrate then both to Gitea, but having to understand Gitea database, then Redmine database and then creating/testing a script to migrate everything is a bit too much.

[ghost]

Given tags come across just fine I'm guessing the bane of this issue is people losing release notes which they stored in GitHub releases as opposed to a ChangeLog. To generate a changelog file from git history take a look at https://www.npmjs.com/package/conventional-changelog-cli

[jonasfranz]

Maybe can we add support for that to the gitea GitHub migrator

[techknowlogick]

Closing this in favour of external tool.