Skip to content
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

handle the case where source repo deleted #12

Open
mhow2 opened this issue May 7, 2018 · 5 comments
Open

handle the case where source repo deleted #12

mhow2 opened this issue May 7, 2018 · 5 comments

Comments

@mhow2
Copy link
Contributor

mhow2 commented May 7, 2018

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 ?

@bachp
Copy link
Owner

bachp commented May 7, 2018

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.

@mhow2
Copy link
Contributor Author

mhow2 commented May 14, 2018

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.

@bachp
Copy link
Owner

bachp commented May 14, 2018

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?

@mhow2
Copy link
Contributor Author

mhow2 commented May 15, 2018

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.

@bachp
Copy link
Owner

bachp commented May 15, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants