search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.03k stars 5.49k forks source link

Migration Summary #8689

Open 6543 opened 5 years ago

6543 commented 5 years ago

Supported Migration Routines:

Features missing on all platform:

this will make the whole system more federated again ... sourcecode is - issues not

Partial Imports ..

6543 commented 5 years ago

note: https://docs.gitea.io/en-us/migrations-interfaces/

lunny commented 5 years ago

And Gitea/Gogs, I have sent a WIP PR to support Gogs.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

viceice commented 4 years ago

I like to migrate from bitbucket server. I know the api very well, but my go expirience is somehoaw little. I found a go package for wrapping the api go-bitbucket-v1. Any hints where to start?

BTW: i'm also interested to migrating from a gitlab self-hostet instance. 🙃

coldcoff commented 4 years ago

See also https://github.com/go-gitea/gitea/issues/11815

When using repository migrations (mirroring) there is already support for public GitHub, that will offer to migrate not only the code, but also Issues, Pull Requests and similar by using the public GitHub API to fetch the additional content.

Please make it possible to do the same also when not using the public GitHub, i.e. the URL "github.com".

There are enterprise GitHub instances out there, typically something like "github.company.com" or so, that will work the same, but they are some "isolated" GitHub.

Currently unfortunately only the code migration is possible from such enterprise GitHub instances.

But as Enterprise GitHub is just "GitHub with different URLs" (and the software version running there is probably a bit older than the public GitHub) the task is hopefully only to make some hardcoded GitHub URLs configurable/extendable.

So it might be a lower hanging fruit. This is not really a new platform / new migration, but an extension to the existing GitHub migration.

lunny commented 4 years ago

@6543 I would like to rename this one as a migrations summary issue includes platforms, features, enhancements links and etc.

6543 commented 4 years ago

@lunny feel free to change it at any time :)

bjornbouetsmith commented 2 years ago

Hi, Any plans to support migration from on prem Azure DevOps (git) to gitea?

I have tried and it just fails - possibly because authentication in azure devops is not using basic authentication but something else?

It just logs:

May 19 18:15:27 git gitea[687]: #033[36m2022/05/19 18:15:27 #033[0m#033[32m...ervices/task/task.go:56:#033[32mhandle()#033[0m #033[1;31m[E]#033[0m Run task failed: #033[1mAuthentication failed: Clone: exit status 128 - fatal: Authentication failed for 'http://devops.root.dom/ROOT/common/_git/Helm/'

I am 100% certain that the username/password combo is correct, since I use it on a daily basis - and also can access the repo from another service - using the exact same combo.

I also have this in my app.ini

[migrations]
ALLOW_LOCALNETWORKS = true

My guess is that it is probably because I have a "special" character in my password and when I turn on debug logging I can see the url it tries to clone - and if I copy/paste that URL and do a manual git clone from the prompt - I also get the same:

fatal: Authentication failed for 'http://devops.root.dom/ROOT/common/_git/Helm/'

If I do a 

git clone http://root%5Cbbs@devops.root.dom/ROOT/common/_git/Helm

And manually type in the password - it just works.

I have no idea if its some kind of escaping that happens that messes up the http request inside git - or if its simply wrongly escaped from gitea's side.

Do I just have to accept this?

According to "people" on the internet, then it seems to have been escaped correctly according to https://en.wikipedia.org/wiki/Percent-encoding - but no dice - I have used other systems in the past that did not like my password.

To give a hint about what character that messes it up - its # - which I know is bad in a url - but I refuse to change my password just because some systems do not like it.

wget on the other hand just accepts the encoded url - so I am beginning to think its a bug in git.

Edit:

Just tested on a windows machine and git clone just works with the encoded url (git version 2.33) - on the gitea server (Rocky Linux) - git version 2.27.0 it fails - so either its a bug that is fixed in 2.33 - or an OS issue that is causing this.

Edit2: Updated git to version 2.31 on the server - and its the same issue. So I am thinking its a git on linux issue.

6543 commented 2 years ago

if it's about "raw GIT" migration ... I think it's a bugreport ... nothing we should track here @bjornbouetsmith - could you create a new issue with the info you posted here :) (github should be able to make your comment a own issue)

bjornbouetsmith commented 2 years ago

if it's about "raw GIT" migration ... I think it's a bugreport ... nothing we should track here @bjornbouetsmith - could you create a new issue with the info you posted here :) (github should be able to make your comment a own issue)

Done #19772 - Although I am beginning to think its not a gitea issue - and just a git on linux issue

woj-tek commented 2 years ago

Suggestion: Import projects/issues from youtrack