Self-Healing CI: Auto-Retrying Git Clone and Fetch Failures
A clone or fetch that drops mid-transfer is a network failure, not a repository problem - the same clone usually completes cleanly on a retry.
The problem
A git clone or git fetch fails partway through with an early EOF, a reset connection, or a remote hang-up. The repository, ref, and credentials are all valid; a human re-runs the job and the clone completes with no change.
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: unexpected disconnect while reading sideband packetWhy it happens
Cloning a large repository moves a lot of data over a single connection. A brief network blip, a server-side timeout, or memory pressure on the remote during pack generation can drop that connection before the transfer finishes.
Deep histories and large objects amplify the exposure: the longer the transfer, the more likely it crosses a transient bad moment - none of which reflects anything wrong with the repo or your pipeline.
The manual fix
Manual mitigations for clone/fetch flakiness:
- Re-run the job to retry the clone.
- Shallow-clone (
--depth) or fetch fewer refs to shrink the transfer and its failure window. - Wrap the clone/fetch in a bounded retry loop so a single dropped connection does not fail the step.
git clone --depth=1 <url> || (sleep 5 && git clone --depth=1 <url>)How this gets automated
A dropped clone or fetch has a recognizable transient signature, and the safe response is to retry the transfer. A self-healing CI pipeline detects the transport failure, retries the clone with backoff, and only surfaces the step if the repository is genuinely unreachable or the credentials are wrong - so a flaky transfer never fails the build.