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

Friction report: repo cloning aborted after 1 hour #62577

Open
bahrmichael opened this issue May 9, 2024 · 0 comments
Open

Friction report: repo cloning aborted after 1 hour #62577

bahrmichael opened this issue May 9, 2024 · 0 comments

Comments

@bahrmichael
Copy link
Contributor

With this issue I want to report some friction I encountered when asking my local sourcegraph instance to clone the chromium/chromium repo. With 40GB that repo is especially large, and may not be what our customers usually use.

I wanted to clone this repo to replicate an issue with code insights where I need to run queries that turn out super expensive given the codebase.

Since there was a failure (not sure why, probably because I was switching from wifi to ethernet at that point) on the overall list of repositories in sourcegraph, I switched to the individual repo's view. There I could see the progress it was making, and what I think was 1.5-2 hours in, I see a message that the cloning has been aborted because it exceeded the 1 hour threshold. I've only seen this message when I opened the details of the repo being cloned in sourcegraph, and assume that this info is not surfaced when we show at the overall list of repos in my sourcegraph instance.

Screenshot 2024-05-08 at 21 47 00

I saw the message below, and recalled that I can clone a repo and use another command to serve that up to sourcegraph. But since I didn't know about the timeout and found the cloning process easier, I didn't go that route.

After looking into the code I saw that the timeout can be configured via gitLongCommandTimeout, and would suggest to surface the possibility of hitting the timeout before it happens and a user basically has to start over.

Maybe we can track the remaining time, and/or show a note that if the download takes especially large it would be aborted after an hour and that the timeout can be configured via gitLongCommandTimeout?

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

No branches or pull requests

1 participant