git-mirror icon indicating copy to clipboard operation
git-mirror copied to clipboard

handle the case where source repo deleted

Open mhow2 opened this issue 6 years ago • 5 comments

In the context where the tool in ran from a cron job, I'm looking for a way to handle the case where the source repository defined in the origin field in Gitlab's project description is not available anymore and do something if so - currently I'm thinking about automatically delete the mirrored repo/project in GitLab.

In the current state, if you define origin to a (github) repo that does not exist (or not anymore), git ask for authentication - and this is reported as an error by git-mirror (error output).

Actually I could parse the output of the tool but relying on the output format is probably not the best idea in the world if it's going to change :) Would you have an idea ?

mhow2 avatar May 07 '18 10:05 mhow2

You are right the current output format is not stable at all.

I don't like the idea to automatically delete the target repository. The failure might be only temporary and might start to work again.

On possible solution might be to add an option to produce a machine readable report at the end that has a stable format for example in JSON. This way you could parse that report and take the appropriate actions.

bachp avatar May 07 '18 12:05 bachp

I don't like the idea to automatically delete the target repository. The failure might be only temporary and might start to work again.

You're right it I don't like it either. But still my concern is in the might word... Of course there can be network issues but I need to make sure that my mirrored repo are always in sync with the related one in Github. So for now I suppose that the report case where a repo could not be retrieve should be handled manually... I could do this by manually capturing/inspecting stderr from the tool.

mhow2 avatar May 14 '18 10:05 mhow2

As mentioned I don't consider the current out put stable in any way.

What's your opinion about a machine readable JSON report that can optionally be generated?

bachp avatar May 14 '18 18:05 bachp

Of course JSON would be great ! But what I meant is it's not a huge priority for me : the output can be reviewed by hand for now.

mhow2 avatar May 15 '18 06:05 mhow2

Ok I understand. I will keep this on the backlog as an enhancement.

bachp avatar May 15 '18 20:05 bachp