Description
What version of Go are you using (go version
)?
$ go version go version go1.18.1 linux/arm64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="arm64" GOBIN="" GOCACHE="/home/myitcv/.cache/go-build" GOENV="/home/myitcv/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="arm64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/myitcv/gostuff/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/myitcv/gostuff" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/myitcv/gos" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_arm64" GOVCS="" GOVERSION="go1.18.1" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" 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 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2711956463=/tmp/go-build -gno-record-gcc-switches"
What did you do?
When a new commit is submitted to the tip of CUE, the following CI step runs:
v=$(git rev-parse HEAD)
cd $(mktemp -d)
go mod init mod.com
GOPROXY=https://proxy.golang.org go get -d cuelang.org/go/cmd/cue@$v
i.e. we intentionally pull that commit through the proxy. Occasionally, this gives output similar to:
go get: cuelang.org/go/cmd/cue@236a565379907bc92997645e4113ca1ed6c499b6: invalid version: reading https://proxy.golang.org/cuelang.org/go/cmd/cue/@v/236a565379907bc92997645e4113ca1ed6c499b6.info: 410 Gone
server response: not found: cuelang.org/go/cmd/[email protected]: invalid version: missing cuelang.org/go/cmd/cue/go.mod at revision 236a56537990
This happened twice today (times in parentheses):
- https://github.com/cue-lang/cue/runs/7363942087?check_suite_focus=true (2022-07-15T19:32:09.7365051Z)
- https://github.com/cue-lang/cue/runs/7359795770?check_suite_focus=true (2022-07-15T14:38:49.0182148Z)
This error also happens as part of another CI workflow, where we try to go get
the default branch (master
) through the proxy.
Per an exchange with @bcmills on Slack, I'm creating this issue to track how often this occurs.
A retry is almost always sufficient to "fix" this failure, but when this happens as part of CI, the retry is significantly more involved.
What did you expect to see?
No errors. The commit is definitely there, and in the case of the default branch, that's never not been there.
What did you see instead?
As above.
Please let me know if there are any specific details that would help in tracking down the cause.
cc @mvdan