cmd/go: git remote did not send all necessary objects #59044
Labels
GoCommand
cmd/go
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Comments
jpduckwo
changed the title
|
Can you show us the output of the |
|
Logs from CICD failing on two different branches. Note repo name is updated for privacy. Also note the CICD is v1.20.1 (not .2) Click to see logs |
|
That's a git error, I don't think there's anything go can do about it |
seankhliao
added
the
WaitingForInfo
|
@seankhliao maybe so, but why does it only happen with v1.20 then? Is the git command changed? |
|
the git commands go runs are in the log you posted, perhaps it was your git version that changed and not go? |
seankhliao
added
WaitingForInfo
|
The CICD environment is unchanged apart from the goenv installed go version, here are the successful logs from v1.19 Click to see logs |
|
Here are the git commands filtered EDIT: |
|
I believe this may be related to local corruption of the caches somehow and will reopen if not |
|
After more investigation, I have ruled out any existing broken cache causing the problem. I have run It's like the git folder it is setting up the first time it is run is missing some information with v1.20 Here is a diff. Note the missing objects/pack files and shallow file in the broken one... Click to view folder diff of working vs not working 👈@seankhliao any ideas? Any more info / tests I can provide? EDIT: reiterating that it all works fine on v1.19 |
seankhliao
added
WaitingForInfo
|
Running v1.19.7 vs v1.20.2 goget-v1.19.log - working fine There must be something in the structure of the folder that it creates for the repo so that it is different and fails for 1.20.2... anyone got any ideas? |
|
Hello! I had a similar issue with git a few weeks ago and found this blog post, hope it helps! I've ran into this error a few times now in unrelated projects. |
|
Thanks @dingeldeiner, I can't run git gc it on the AWS CodeCommit repo so not sure that it helps me. If I run gc on my local copy (not the go mods dirs) it doesn't present any issues to be fixed. If I clone --bare the entire repo I also don't have any issues. I don't understand how it can be a git issue when it all works fine with version 1.19? |
seankhliao
added
WaitingForInfo
|
@jpduckwo Hello, I have also encountered the same problem, have you already solved it? |
|
Hi @ywooer, no, we have just stuck with 1.19. I was waiting to see if anyone else reported having the same issue. I did some combing through the logs to try and find out what was happening differently on 1.20.2 and the furthest I got was the way Go initialises the folder before pulling the code. I still think the issue is with the behaviour of Go and not my repo based on my tests. Do you see the exact same symptoms? |
|
@jpduckwo Yes, I tried |
|
Hi, update from my side. We tested further with v1.21:
So overall this issue is still there, and the process works fine with 1.19 As a permanent workaround for the issue we changed the build process to git clone the repo into a new folder and do a It would be great if this was fixed one day - I'm pretty sure it's something to do with the folder structure that go get sets up before it does the clone. Maybe it's the local git version of CodeCommit that doesn't like this new way. |
|
I think waitingforinfo tag isn't applicable here any more |
|
@gopherbot please remove label WaitingForInfo |
gopherbot
removed
the
WaitingForInfo
cherrymui
added
the
NeedsInvestigation
|
@jpduckwo, what Git server implementation is being used to serve the repo? (Is it the mainline The reason I ask is because the last time we saw this kind of error (in #31399) it was due to a JGit implementation bug. If CodeCommit is using an outdated or buggy Git implementation, that should be fixed on the CodeCommit side, not worked around on the Go side. (#56881 leads me to believe that there is a bug in Go's Git handling, but that bug does not manifest as a |
bcmills
added
the
WaitingForInfo
|
Hey @bcmill, thanks for your reply. I will reach out to AWS to see if they can divulge the git server version that CodeCommit uses. I have said this several times already, but just reiterating that this all works with version 1.19 perfectly fine. Was there some git work-around that was removed in 1.20+? Something has changed in Go that caused this break. However, I do agree that Go shouldn't have to work around any buggy server issues. But also, I've not heard of, or experienced any issues with other tooling used with CodeCommit, and I've been using it for 7 years. |
seankhliao
added
WaitingForInfo
|
@ywooer Just checking if your issue was also with CodeCommit? |
seankhliao
added
WaitingForInfo
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
|
AWS came back and said that CodeCommit is using a custom git server underneath the hood - not JGit just FYI |
Thank You dingeldeiner, it is Worked for me. |
Thank you |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes - inconsistently
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Seems very similar to old issue #31399
Getting inconsistent results when running go get command on a CodeCommit git repo. In the form of:
go get -x git-codecommit.ap-southeast-2.amazonaws.com/v1/repos/x.git@<branch>The command fails inconsistently with
Using the local machine, switching the branch name sometimes got it to work. However, using our CICD pipeline the command seems to always fail no matter the branch.
It doesn't fail ever with go version 1.19 - so there doesn't appear to be a problem with the repository.
EDIT: also noting that the commit hash that it complains about is different on different branches that we try it on
What did you expect to see?
The command successfully completes which is the case when switching back to v1.19
What did you see instead?
did not send all necessary objectsThe text was updated successfully, but these errors were encountered: