Closed eseliger closed 7 months ago
Workaround that we used:
This is an issue, because clone
clones to a tmp dir first, and if the post fetch actions fail, it removes it.
For updates, however, we run git fetch right inside the dir at the target location. So even if post actions fail, an update will persist the changes.
We make use of that and create an empty repo on disk in the expected location. After a server restart, it'll be marked as cloned in the DB, after ~45s, repo-updater should trigger a git fetch, and eventually populate the repo, even if the post fetch action fails again. In followup fetches, the post actions should pass again, because we won't run into timeouts.
To do that: Assume github.com/sourcegraph/src-cli
is the repo failing.
Run: mkdir -p /data/repos/github.com/sourcegraph/src-cli
, then initialize a repo using git -c init.defaultBranch=main init --bare /data/repos/github.com/sourcegraph/src-cli/.git
.
Then restart gitserver.
On a customer instance we recently saw a clone take so long that the installation token would expire in between the start of the clone where the token is refreshed and the point at which we run
git remote show ${remoteURL}
.