feat(dev): add migrate-repos tool to handle local > forgejo mass upload #9

This file should not be changed in this PR.

For dev, it is recommended to leave the default because we want to know if the service experiences an outage due to our actions.

Which is precisely what this will let us do - get to the logs of the service that stops - otherwise, to my knowledge, those logs can't be retrieved?

They can the same. You can get logs for stopped containers (services in here).

I will not change this honestly - don't see a big deal in keeping it and if the service keeps crashing, it will let us know on it's own.

Not quite, you might miss some failures unless you observe the process.

Fine, fixed

You can make this more specific by ignoring ./migrate-repos instead.

s/script/tool

Why not forgejo?

Either I am dumb or the sdk for forgejo isn't nowhere to be found?

No idea, asked on matrix.

It seems it does not exist.

This should have been handled for you via the shell and file-related modules and should not be necessary to handle yourself.

Care to give an example of that? AFAIK, from my internet search, this is the correct method (maybe one doesn't have to check for $HOME, but for ~/ we do have to, surely?)

https://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html

We don't need to do this. I mean, many tools out there will fail when given a tilde that has not been processed by the shell.

Fixed, tested it and it works fine.

This is going to be expensive - it would be easier and faster to assume a certain structure to this, e.g., that the tool is given a directory with org/repo structure. This way you can work on a single org a time (first try to create the org, then all the repos) and you don't need to filter for anything else.

doesn't feel expensive and gives quite a lot of flexibility - the bottlenecks of this tool definitely aren't here

You don't seem to retry the repo creation in this case.

Good catch, done

I wonder if we really need to. I mean, we can access the file storage directly - we can write to it oob. More so, we can already point gitea to the existing repos. In case of OpenDev, it's Gerrit that managed the repos and Gitea is only a frontend that shows them so there is no "pushing" to Gitea taking place (afaiu).

🤷 I am not against alternative/additional implementation options, however this will work against any git server endpoint and that seems worth keeping

As mentioned on the chat, using cobra would make CLI parsing much nicer. Though this is good enough for this simple utility.

I looked into Cobra yesterday, but honestly couldn't figure it out. Once I discovered flag.VisitAll() it was quite smooth sailing even for validating that we have all the flags that we need.