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

cmd/go: go get private_module@version_tag fails if the same commit has been downloaded with pseudo-version previously (before being tagged) #51374

Closed
central182 opened this issue Feb 26, 2022 · 3 comments

Comments

@central182
Copy link

central182 commented Feb 26, 2022

What version of Go are you using (go version)?

$ go version
go version go1.16.14 linux/amd64

Does this issue reproduce with the latest release?

Yes. I've tried 1.16.14 and 1.17.7. (Inside Docker containers from images golang:1.16.14 and golang:1.17.7 respectively.)

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY="github.com/central182"
GONOSUMDB="github.com/central182"
GOOS="linux"
GOPATH="/go"
GOPRIVATE="github.com/central182"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.14"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/root/example/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4247023591=/tmp/go-build -gno-record-gcc-switches"

What did you do?

On my host machine

  1. Create a private Go module. (Say it's hosted on https://github.com/central182/foobar and the latest commit is ef2f664, with tag v1.0.9 pointing to some earlier commit.)
  2. Launch a Docker container that is able to access my private repositories on GitHub.
$ docker run -it -v /home/me/shared_ssh:/root/.ssh golang:1.16.14

Inside Docker

  1. Do the necessary configuration for downloading private Go modules via SSH.
$ export GOPRIVATE=github.com/central182
$ git config --global url."ssh://git@github.com".insteadOf "https://github.com"
  1. Create a temporary Go module.
$ cd ~ && mkdir example && cd example && go mod init example
go: creating new go.mod: module example
  1. Get the foobar module with its latest commit hash ef2f664.
$ go get github.com/central182/foobar@ef2f664
go: downloading github.com/central182/foobar v1.0.10-0.20220226164108-ef2f6641951f
go get: added github.com/central182/foobar v1.0.10-0.20220226164108-ef2f6641951f

On my host machine

  1. Tag ef2f664 with v1.0.10 and push it to GitHub.
$ git tag v1.0.10
$ git push --tags
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:central182/foobar.git
 * [new tag]         v1.0.10 -> v1.0.10
$ git log --oneline
ef2f664 (HEAD -> main, tag: v1.0.10, origin/main) Empty commit

Inside Docker

  1. Try to get the foobar module with the tag v1.0.10, and watch it fail.
$ go get github.com/central182/foobar@v1.0.10
go get: github.com/central182/foobar@v1.0.10: invalid version: resolves to version v1.0.11-0.20220226164108-ef2f6641951f (v1.0.10 is not a tag)
  1. However, if I repeat step 7 again, the download will succeed.
$ go get github.com/central182/foobar@v1.0.10
go: downloading github.com/central182/foobar v1.0.10
go get: upgraded github.com/central182/foobar v1.0.10-0.20220226164108-ef2f6641951f => v1.0.10

What did you expect to see?

No failure at step 7.

What did you see instead?

The tag did exist while go said otherwise.

@mengzhuo
Copy link
Contributor

Duplicate with #51312

@m1o1
Copy link

m1o1 commented Mar 2, 2022

Seems the duplicate issue changed to narrow the scope and this seems like a different issue now. We also ran into a similar issue as the one here.

@central182
Copy link
Author

Now 1.18.4 is out

supposedly fixing #51312 according to #53588

but I can still replicate the issue with the exact steps I described earlier.

@mengzhuo Could you please take a look into this? Or should I create a new issue instead?

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

No branches or pull requests

4 participants