cmd/go: module fetch errors are unclear #26594
Comments
|
If you're on an older versison of Git, this might be #26501. But I agree that the errors should be clearer. |
|
#26501 is now closed, but adding some suggestions from that issue that could help future troubleshooting: Consider extending what gets emitted by
And/or address TODO from modload (#26501 (comment) from @rogpeppe):
|
|
I just tried one of those git commands and as it happens it does return exit code 1 without printing any error, so perhaps the problem is with git itself. I am using git 2.7.4. |
|
I could move off git 2.7.4 but as it's the default version you get when using Ubuntu 16.04 I think it's important that Go works correctly with that version. |
|
BTW I just tried with a newer version of git (2.18.0) and everything works OK. |
|
I'm not sure what more to do here. I would like to turn off the finding prints by default, although I worry that people will think the go command is just stuck if it's not printing those. But this is very precise: It contains enough information to repeat the command, and as you found, something is wrong with that git command. I suppose we could make it say "cd dir && git fetch" instead of "git fetch ... in dir". What's unclear is git here, I think. Does anyone have any idea what is wrong with git 2.7.4? Does it not support --depth=1? |
|
This is not conclusive, but https://github.com/git/git/blob/v2.7.4/Documentation/fetch-options.txt#L10 |
|
for what its worth git 2.7.4 and go head works fine for me. |
|
@rogpeppe can you try running one of the git commands with some of these verbose env vars set https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems |
bcmills
added
the
NeedsInvestigation
|
@gopherbot, please add label help wanted |
|
#25982 (comment) is related here. Whilst as @rsc notes in #26594 (comment) we shouldn't/don't have to log the finding statements, we can log the output in case of error. |
|
This issue #26594 is slightly complicated by the fact that apparently here outputting errors from git would not have helped here (because here git was silent), but it seems outputting errors from git would have helped other issues, e.g., see #26594 (comment) |
|
@thepudds is there any thoughts on when running go in verbose mode running git fetch with one of those verbose flags mentioned in my link? Just thinking about how we can give people the tools they need to debug these issues without filing an issue every time. https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems |
|
Ok, unless I've missed this above, there appears to be something orthogonal to the git version that is affecting things here, above and beyond any differences in behaviour introduced by the git version itself. Consider the following as context, which is roughly the state one of my CI builds get into via various Go commands: The build was failing because, ultimately, the following git (2.11.0) command failed: It fails with exit code 1 and no output to stdout or stderr. A non-zero exit code is fine, but the empty stdout and stderr is not expected ( ) and hence the Go command ultimately fails.If I try and reproduce this locally (using the same docker container), I instead get exit code 128 and some error output, specifically the expected output: gives As far as I can tell, this is exactly the same setup as my CI build; same docker image, git version (2.11.0) etc. But something is clearly different (I'm probably missing something obvious); I just unable to recreate the environment/scenario in which that git command gives an exit code of 1. I also can't reproduce the exit code 1 using git 2.7.4: However, @rogpeppe, with a standard Ubuntu 16.04 setup (git 2.7.4) can reproduce the exit code 1. At this stage, we're unclear what is different between our environments/setups that causes this difference in behaviour. Any help/thoughts much appreciated (and apologies if any of this repeats what's gone before, to be honest I'm totally lost at what's going on here). |
|
@mvdan has the answer 🎖 This particular case appears to be affected by the use of an ssh-based git remote. Using git 2.11.0 (because this particular command is not a problem with more recent git versions) and assuming an appropriate ssh setup: gives exit code 1 and no output. Using an https-based remote: gives exit code 128 and the following output (which is what we want/need): I haven't looked into possible solutions, so this is just to note findings so far. |
|
Sorry, another message in this thread I'm seeing the aforementioned behaviour on CircleCI v2 (which has git 2.11.0), so not an uncommon setup people will be using. CircleCI globally sets |
|
We fixed this particular error, which was really git's fault. |
What version of Go are you using (
go version)?go version devel +5f5402b Tue Jul 24 23:54:08 2018 +0000 linux/amd64
What did you do?
This produced the following output:
It's clear that some of the git fetch commands failed, but because all the actual error output is discarded, it's not possible to see why. "exit status 1" doesn't convey any significantly useful info, so it's hard to know what went wrong and hence how the problem might be resolved.
The text was updated successfully, but these errors were encountered: