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: spurious "v1.x.y is not a tag" error when a tag's commit was previously download without the tag #53955

Closed
central182 opened this issue Jul 19, 2022 · 10 comments
Assignees
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@central182
Copy link

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

$ go version
go version go1.18.4 linux/amd64

Does this issue reproduce with the latest release?

Yes. I was able to reproduce from Docker image golang:1.18.4.

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=""
GOEXPERIMENT=""
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.18.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/root/example/go.mod"
GOWORK=""
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-build856782336=/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.18.4

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.

@central182
Copy link
Author

I have posted this issue before as #51374 but was told it was duplicate to #51312.
Now that the fix to #51312 is released with 1.18.4 (according to #53588) I believe they are different issues.
Possibly related to #51312 (comment)?

@bcmills
Copy link
Contributor

bcmills commented Jul 20, 2022

Thanks for the detailed repro steps — I had not seen the prior issue you filed. I agree that this looks like a different root cause.

@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Jul 20, 2022
@bcmills bcmills added this to the Go1.20 milestone Jul 20, 2022
@bcmills bcmills self-assigned this Jul 20, 2022
@bcmills bcmills modified the milestones: Go1.20, Go1.21 Dec 12, 2022
@bcmills bcmills added the GoCommand cmd/go label Dec 12, 2022
@bcmills
Copy link
Contributor

bcmills commented May 11, 2023

This is plausibly related to #56881.

@markbastiaans
Copy link

Also hitting this issue with Go 1.20.4, private modules (GOPRIVATE set, git insteadOf configured) on an Azure Pipelines runner container (based on Ubuntu 22.04).

I cannot reproduce this issue locally, so my suspicion is that that this issue might be related to the containerized environment.

@gopherbot gopherbot modified the milestones: Go1.21, Go1.22 Aug 8, 2023
@bcmills
Copy link
Contributor

bcmills commented Dec 4, 2023

I have a test script that reproduces this behavior locally; I hope to have a fix ready for Go 1.22 or shortly thereafter.

@gopherbot
Copy link

Change https://go.dev/cl/547155 mentions this issue: cmd/go/internal/modfetch/codehost: add new git tags before statLocal instead of after

@bcmills
Copy link
Contributor

bcmills commented Dec 6, 2023

@gopherbot, please backport to Go 1.21 and 1.20. This fixes a bug that is otherwise difficult for users to understand and diagnose, and the fix is relatively uninvasive.

@gopherbot
Copy link

Backport issue(s) opened: #64585 (for 1.20), #64586 (for 1.21).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@bcmills bcmills changed the title cmd/go: Go 1.18.4 still complains "v1.x.y is not a tag" if the target (private?) module had been once downloaded before being tagged cmd/go: spurious "v1.x.y is not a tag" error when a tag's commit was previously download without the tag Dec 6, 2023
@gopherbot
Copy link

Change https://go.dev/cl/548215 mentions this issue: cmd/go: set global .gitconfig location more robustly in tests

gopherbot pushed a commit that referenced this issue Dec 7, 2023
Also confirm that setting the location actually worked before
proceeding with the rest of the test.

This fixes a test failure with git versions older than 2.32.0.

Updates #53955.
Fixes #64603.

Change-Id: I1a954975a3d8300e8b4dca045d3a15438a0407ec
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/548215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
@bcmills
Copy link
Contributor

bcmills commented Dec 7, 2023

If we backport this fix, it needs to include both CL 547155 and CL 548215 to avoid breaking the builders.

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 1, 2024
ezz-no pushed a commit to ezz-no/go-ezzno that referenced this issue Feb 18, 2024
…instead of after

gitRepo.statLocal reports tag and version information.
If we are statting a hash that corresponds to a tag, we need to add that tag
before calling statLocal so that it can be included in that information.

Fixes golang#53955.
Updates golang#56881.

Change-Id: I69a71428e6ed9096d4cb8ed1bb79531415ff06c1
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/547155
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
ezz-no pushed a commit to ezz-no/go-ezzno that referenced this issue Feb 18, 2024
Also confirm that setting the location actually worked before
proceeding with the rest of the test.

This fixes a test failure with git versions older than 2.32.0.

Updates golang#53955.
Fixes golang#64603.

Change-Id: I1a954975a3d8300e8b4dca045d3a15438a0407ec
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/548215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants