Sidecar crashes with unreachable git repo about git-sync HOT 9 CLOSED

In my view failing hard on initialization is good. Let's you dig for the actual issue. Also, that only means the container fails, which in the Kubernetes context might be restarted anyway.
I think that is ok.
What this issue is mostly about is that when the files are already available locally (even if they might be out of date), if the git repo gets unresponsive, the container will crash and go from an out of date and functioning state to an unfunctioning one.

from git-sync.

@stp-ip, is there any way to move forward with this request?

from git-sync.

I have cut a release-2.0 branch, which makes head 3.0 ready. We maybe want to change this behavior to always retry, but we need to define how it intersects with one-shot mode.

from git-sync.

I might have some time from juniors available in the coming months. They might give a full go implementation a shot with a few features including "fixing" this.

from git-sync.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

from git-sync.

/lifecycle frozen
/remove-lifecycle stale

from git-sync.

Patches welcome...

from git-sync.

@stp-ip or @thockin Just want to get your opinion on something.

• Current behaviour is that on https://github.com/kubernetes/git-sync/blob/master/cmd/git-sync/main.go#L170 - in the initial sync if this occurs it hard fails as well. Shouldn't it be okay to keep retrying even though initial failed ?

from git-sync.

The "files partially exist" bug has been fixed. I think crashing if the repo doesn't exist is appropriate, so I am going to close this

from git-sync.