Question: How to best automate loading up a blank Gitea with our stack and setup mirroring #27

Open
opened 2023-04-06 22:45:53 +00:00 by zramsay · 5 comments
Member

Context: I can reliably stand up the package-registry stack (which maybe isn't a broad enough name) but am not sure what the next step would be to efficiently and reliably "load" all our GH repos, mirrored from GH. It's easy enough to do manually :(

Of course, the goal is the reverse the mirror at some point but IMO a good first step is to get S-O to spin up gitea with all of GH mirrored; this would also be a great task to assign the membership...use S-O to host a mirror of our stack in gitea. Once we switch, S-O would be configured to run a gitea mirror from the authoritative gitea.

https://docs.gitea.io/en-us/repo-mirror/ --> nothing about automating this

https://github.com/maxgallup/gitea-migrate --> most recent tool I could find

Context: I can reliably stand up the `package-registry` stack (which maybe isn't a broad enough name) but am not sure what the next step would be to efficiently and reliably "load" all our GH repos, mirrored *from* GH. It's easy enough to do manually :( Of course, the goal is the reverse the mirror at some point but IMO a good first step is to get S-O to spin up gitea *with all of GH mirrored*; this would also be a great task to assign the membership...use S-O to host a mirror of our stack in gitea. Once we switch, S-O would be configured to run a gitea mirror from the authoritative gitea. [https://docs.gitea.io/en-us/repo-mirror/](https://docs.gitea.io/en-us/repo-mirror/) --> nothing about automating this [https://github.com/maxgallup/gitea-migrate](https://github.com/maxgallup/gitea-migrate) --> most recent tool I could find
Owner

I think this would be a case of reviewing the GT code, finding the back-end area that implements the migrate button and then seeing if it is wired up to the API. There may be some chatter about this in their issues or Discord.

If it's not API-aware, then next step would be to add that code, or wait for someone else to do it.

I think this would be a case of reviewing the GT code, finding the back-end area that implements the migrate button and then seeing if it is wired up to the API. There may be some chatter about this in their issues or Discord. If it's not API-aware, then next step would be to add that code, or wait for someone else to do it.
Owner
We now have a tool to help with this: https://github.com/cerc-io/hosting/blob/main/gitea/migrate-repo.sh
Author
Member

I get "Illegal number of parameters" as a response, after editing the last line to not pipe to jq for the html_url. Investigating further

solved by removing quotes around export CERC_GITEA_API_URL='gitea.local:3000'

> I get "Illegal number of parameters" as a response, after editing the last line to not pipe to jq for the html_url. Investigating further solved by removing quotes around `export CERC_GITEA_API_URL='gitea.local:3000'`
Author
Member

got it working, had to create a new token that had the repo scope. The default token from running the package-registry stack had package and sudo scopes ... I guess sudo doesn't mean what I expected to mean 🤷

got it working, had to create a new token that had the `repo` scope. The default token from running the `package-registry` stack had `package` and `sudo` scopes ... I guess sudo doesn't mean what I expected to mean 🤷
Author
Member

#42

#42
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/hosting#27
No description provided.