feat(gitter): Stop trying to make fetch happen#5299
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
| if isIndexLockError(err) { | ||
| logger.WarnContext(ctx, "index.lock exists, attempting to remove") | ||
| indexLockPath := filepath.Join(repoPath, ".git", "index.lock") | ||
| if err := os.Remove(indexLockPath); err != nil { | ||
| logger.ErrorContext(ctx, "failed to remove index.lock", slog.Any("err", err)) | ||
| return false | ||
| } | ||
|
|
||
| return true | ||
| } | ||
|
|
||
| // Refname conflict, likely name conflict between local and remote refs | ||
| // We can try removing stale remote-tracking branches and retry | ||
| if isRefConflictError(err) { | ||
| logger.WarnContext(ctx, "ref conflict detected, running git remote prune origin") | ||
| if err := runCmd(ctx, repoPath, nil, "git", "remote", "prune", "origin"); err != nil { | ||
| logger.ErrorContext(ctx, "failed to prune origin", slog.Any("err", err)) | ||
| return false | ||
| } | ||
|
|
||
| return true | ||
| } |
There was a problem hiding this comment.
I think this is even being too clever, now that we have graceful shutdowns, how often do these issues actually come up?
I'm leaning towards just always reclone at the first sign of trouble.
There was a problem hiding this comment.
The index.lock fix has been in gitter since #4816 so I don't really have stats for it.
For the second case (refname conflict). We’ve seen this issue in 7 repos over the past week in our test env.
It happens when, for example:
- A repo starts off with a
fixbranch - Gitter clones / fetches at this point (we now have a local ref
fix). - Afterwards, the branch can be renamed upstream to
fix/some-other-name. Similarly they could have deleted thefixbranch and started some more branches under thefix/prefix. - When gitter fetches again, the refname conflict will happen as git doesn't differentiate between directory and files. So the local
fixref name will be in conflict with every branch upstream that starts withfix/.
That said, this is not a hill I'm dying on, so I'm happy to change to just using reclone as the fallback.
There was a problem hiding this comment.
Let's keep this second case. For the first case I think let's reclone, and log it so we know how often this happens.
4 participants
Gitter will attempt to solve a few common git errors (index.lock file exists, and refname conflict) when git fetch and reset fail.
If that doesn't fix the git fetch, fallback to a fresh reclone instead of redoing fetch on a broken repo next time.