-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature, bulk importing of repositories #2569
Comments
You can do migrations via API. Write some scripts to do that. |
Such migrations should be done in scripts or external tools but should not be part of main gitea repo |
Any pointers to valid Github-to-Gitea scripts? I come up empty. |
@tacotexmex currently @JonasFranzDEV has a really good one: https://git.jonasfranz.software/JonasFranzDEV/gitea-github-migrator |
Thank you very much @tecknowlogick. * quietly thinking how I could’ve discovered this selfhosted gem without your help, dreaming of a federation of Gitea instances, Mastodon-style * |
@tacotexmex you are very welcome. Currently there is a working group that is dedicated to solving the issue of federated services. I actually just spent the morning catching up on discussions from the group. If you want to follow along you can see: forgefed/forgefed#5 Unrelated to federation we have a discord channel where the above tool was posted to. |
@lafriks why? i think migration should be as simple as possible. imagine a workflow like this:
if load on the gitea server could be a problem, a queue could be implemented. |
@davidak while I agree that it should be as simple as possible but if we implement imports from github/bitbucket/gitlab etc it will be hard keep up with their api changes. There is example that it can be easily done outside of Gitea main code base - https://git.jonasfranz.software/JonasFranzDEV/gitea-github-migrator Of course there are few things that we need to implement in Gitea API to have possibility to import more data but that's other thing |
Anyone have a mirror or copy of https://git.jonasfranz.software/JonasFranzDEV/gitea-github-migrator ? The site is throwing a 500 error when trying to either clone the repo locally or even download the source code. |
@JonasFranzDev your server has problems ;) |
Edit, use at your own risk and don't randomly download zips from the internet. |
Cheers guys, thanks 😄 |
https://git.jonasfranz.software/JonasFranzDEV/gitea-github-migrator is back up and states:
I just tested it, it worked flawlessly (Debian 9/10)
Edit: limitation: doesn't import pull requests/release notes. Didn't create the project as "mirror" (no automatic pulls in the future). Repository, issues, tags, wiki were imported correctly. Operation took 11 minutes on a github project with 1300 issues. |
For others coming to this issue, the migration functionality is now built into gitea itself. |
@techknowlogick you mean using the This doesn't import issues/wiki for me, only the git repository. |
@nodiscc @techknowlogick is right. You can migrate almost all things from github. When you input a github URL on migration UI, and put a username/password or token/, then you will find some migrations options displayed, you can check issues/wiki/pull requests/milestones/labels . Of course you have to have v1.9 or above. |
@lunny my bad, I'm on 1.8.0, still have to upgrade. I will definitely try this (my gripe was it didn't set up the repository as mirror and there was no way to change it after the fact). By the way, thank you and all contributors for the hard work on Gitea. I'm in the process of moving all my projects to a self-hosted Gitea instance (with automatic Github/Gitlab mirrors through hooks), it has been great so far. You can find my ansible role to install gitea here (inspired from [1], [2]). |
I think this issue can be closed as bulk import/migration is perfectly doable using https://gitea.com/gitea/migrator/ (which is linked at https://docs.gitea.io/en-us/third-party-tools/) - or one by one from the web interface. |
@lunny ping |
@nodiscc Currently we can import almost all things of one repository from github, but maybe this issue is importing many repositories on one operation. |
I would say this is a feature for tea link: https://gitea.com/gitea/tea/issues/22 |
PS: when tea reaches v1.0 we can add it to gitea docs as tool to automate/do stuff via CLI ... |
Currently the suggested "https://gitea.com/gitea/migrator/" shows:
But "new migration" inside gitea does only migrate a single repository, so this does not help much if one has to migrate hundreds of repos. |
@csarn and others. this is true I wanted to bulk migrate repo's but migratory is 1 repo at a time??? what to do? |
@ameeno best way at the moment: use API via go-sdk or curl ... script |
The other option is to use adopt repository if the repositories are in the right place with the correct names. |
anyone have a script ready for batch migration? I found a Chinese one on awesome-gitea but I am having problems with it it only working for orgs. |
I need to bulk import 80+ repositories from GitLab to Gitea - any pointers for how this could be done? Thanks a lot! |
You can do it via some scripts with migration API. |
sure, I know this is possible. Has anybody written any such script? I couldn't find one... :/ |
Hi any update on it? I have like 300 repos I want to migrate and doing this one by one isnt an issue. the only script I found was at dev.to which doesnt support migration of public vs not or multiple repos. does someone have a github to gitea script for that? :/ |
Try something like this (assumes you have Github cli installed - on Mac you can #! /usr/bin/env bash
GITEA_DOMAIN=http://myserver
GITHUB_TOKEN=
GITEA_TOKEN=
GITHUB_USERNAME=
GITEA_USERNAME=
REPOS=$(gh repo list -L 1000 | awk -F '\t' '{print $1}')
for REPO_NAME in $REPOS; do
echo $REPO_NAME
curl -X POST "$GITEA_DOMAIN/api/v1/repos/migrate" -u $GITEA_USERNAME:$GITEA_TOKEN -H "accept: application/json" -H "Content-Type: application/json" -d "{ \
\"auth_username\": \"$GITHUB_USERNAME\", \
\"auth_password\": \"$GITHUB_TOKEN\", \
\"clone_addr\": \"https://github.com/$GITHUB_USERNAME/$REPO_NAME\", \
\"description\": \"$(gh repo view ${REPO_NAME} --json description --jq '.description')\", \
\"mirror\": false, \
\"private\": true, \
\"repo_name\": \"$REPO_NAME\", \
\"repo_owner\": \"$GITEA_USERNAME\", \
\"service\": \"git\", \
\"uid\": 0, \
\"wiki\": true}"
sleep 2
done What it doesn't do which I wish it did is set up push forwarding of each repo back to Github so I can use Gitea as my primary and maintain a backup on Github. |
I stumbled across this thread too and didn't find a suitable solution for my usecase. So, I created this gist: https://gist.github.com/CodeShakingSheep/5dc2cf6ac3b6d265218a7214f8f1210b No access to Github CLI needed and it works for organization and user repos. If you need user repos, just leave I also created a script for removing the repos from Gitea in case something went wrong. https://gist.github.com/CodeShakingSheep/65a7f46ab6067a72835e13b8459c0f7d |
+1 on this one, in my case it's gitLab not github that I need to migrate from and needing to study a new scripting language or curl just to get it "the right way" it's a bigger nuissance than migrating 20 repos manually, so I'll be doing that for the next half an hour. |
Currently, only the first 100 repos are imported. This script will import all repos. |
I have made some slight tweaks to @boydaihungst 's gist and now it includes setting the org fullname,avatar,link and description (if set). This will also set them to be a mirror by default, behaviour can be changed at the bottom of the script. how-to
|
If I get the time, I might create a dedicated tool for stuff like this |
If anyone cares, I have a basic prototype up and running. Import orgs or users along with their github avatars. Work in progress, but it works. https://gitlab.nyeprice.space/aneurinprice/gitea-bulk-exporter Edit: Add screenshot |
@aneurinprice Looks like your link got 404d? |
@Shinmera Updated link, Will provide documentation soon, but if you are at all familiar with golang then you'll probably be able to figure it out. https://github.com/aneurinprice/gitea-bulk-importer |
@Shinmera credentials should go |
Cool, worked well, though it seems like the DryRun and Verbose arguments don't do anything. Not a big deal in my case, but yeah. |
seems like the DryRun and Verbose arguments don't do anything
Currently they do not do anything, you are quite right. They are on my list of things to fix when I have time. Glad it was useful! Is there any functionality you wish it had? Did the user/org avatars import correctly?
Thank you :)
… On 8 Oct 2024, at 11:14, Yukari Hafner ***@***.***> wrote:
Cool, worked well, though it seems like the DryRun and Verbose arguments don't do anything. Not a big deal in my case, but yeah.
—
Reply to this email directly, view it on GitHub <#2569 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALGJJOB2EOL3P5TFWGZ6CNTZ2OV7VAVCNFSM4D4A4MJ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZZHE2DGOJQGE2Q>.
You are receiving this because you were mentioned.
|
I didn't import any users and the org already existed, so I can't comment on that, sorry! As for features, it would be very good if we could "redirect" which user the repos end up at. After all, it's just a happy circumstance that they are named the same in my case, but they might very well not be. It would also be nice if we could exclude repositories, ideally even by repo type so that forks can be skipped. I have a few trash forks that I should delete now. Wrt docs it would be good if it was described which permissions are needed for the access keys. I kinda guessed with that. |
As per the repository types, this is something I'm already working on. As I, like yourself have loads of old forks. Thank you for your feedback, I'll do my best to get all of these features in :)On 8 Oct 2024, at 11:42, Yukari Hafner ***@***.***> wrote:
I didn't import any users and the org already existed, so I can't comment on that, sorry!
As for features, it would be very good if we could "redirect" which user the repos end up at. After all, it's just a happy circumstance that they are named the same in my case, but they might very well not be. It would also be nice if we could exclude repositories, ideally even by repo type so that forks can be skipped. I have a few trash forks that I should delete now.
Wrt docs it would be good if it was described which permissions are needed for the access keys. I kinda guessed with that.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@lunny Both features currently mostly working on my laptop, will get this tidied up and pushed tomorrow. Just finding a nice way to handle users/orgs with lots of repos.
|
@Shinmera The above was meant for you |
Nice! Great job! |
Recently i hacked about in the back-end and database to migrate all of our stash repositories and jam these into gitea.
It's not an operation that i'll need to repeat, as far as i can tell in the documentation there's no procedure for doing this sort of thing.
I was thinking, as a feature, it might be handy to have an "upload zip" for migration to facilitate easy migration from other git servers.
I'm sure there're higher priorities, but figured it would make it easier for people to migrate and adopt gitea.
Thanks
The text was updated successfully, but these errors were encountered: