How to Use Go Mod Download with Unreleased Pseudo-Versions

Question

Since golang 1.13, I've been having this issue where our docker build scripts, which fetch our dependencies using go mod download , fail during a git fetch if the given dependency is an unreleased pseudo-version that is on a branch.I'm currently using golang 1.15.

I'm trying to integration test some changes to the referenced go package. I'll call the package example-go-sdk . In the git repo for example-go-sdk , I've created a branch and pushed some changes. Then in the golang project that uses example-go-sdk , I've executed:

go get local.url.that.utilizes.goprivate/path/example-go-sdk@824eebca783c68c5ef3cf6db35ad688ad30b58b0

where that hash is the hash of the head commit on my branch, which I've double-checked is correct and does have my changes. The project compiles locally with this just fine. Even the go mod download works for me.

However, when doing the go mod download from a golang:1.15-alpine docker container (after ensuring GOPRIVATE is set correctly), I get this error:

go: local.url.that.utilizes.goprivate/path/example-go-sdk@v1.1.2-0.20210329043657-824eebca783c: invalid pseudo-version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /go/pkg/mod/cache/vcs/369a4408a70eeb73ab52db67cb0c1ba8eb165df174d65c9ec995526a9545424b: exit status 128:
    fatal: unresolved deltas left after unpacking
    fatal: unpack-objects failed

Is there a way to fix this? Due to some other requirements, I can't merge this branch in example-go-sdk to master first before trying to reference it. I've made sure the docker build is using the right version of the referencing project with the updated go.mod and go.sum , too.

Even though this all works locally for me, a couple other team members also have build issues when referencing the pseudo-version, too, so I'm not sure what the deal is.

Answer 1

The go command does and will continue to support pseudo-versions for commits for the foreseeable future. This looks like either data corruption within your repo, or a bug in your git server and/or client.

Since the failing command is the git fetch that attempts to resolve the existing branches and tags in the repo, my guess would be that the issue affects some non-default branch or some existing tag in the repo. That would explain why your pre-release tag workaround works: if the go command can find a specific matching tag, then it doesn't need to fall back to fetching “all branches and tags”, and presumably doesn't trigger the underlying git issue.

You could perhaps start to narrow it down by trying the failing git command in a fresh clone of your repo:

git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/*

Note that you can pass the -x flag to the go command to cause it to (very verbosely!) print all of the git commands it executes. That may help you reproduce an exact repository configuration that triggers the underlying bug.

Answer 2

I was not able to make this work via pseudo-versions. It seems like since golang 1.13 this functionality of using pseudo-versions instead of semantic versions no longer works unless your module still has a major version of v0. It may or may not be related to the use of GOPRIVATE -- I haven't verified that.

However, a workaround is to use pre-release versions as described in the official golang blog . Basically adding a new semantic version but appending a string to the end after a dash: v2.2.2-example.pre.release

By doing this, go mod download was able to find the tag and install the version. Additionally, pre-release tags are not assumed backwards compatible, so users will not automatically get upgraded to that version. They need to explicitly request the pre-release tag.