goproxy.cn: Bug: TLS handshake timeout for **gcexportdata** and **astutil**
What is the output when you execute the go version command?
$ go version go version go1.14.1 linux/amd64
What is the output when you execute the go env command?
go env Output
$ go envGO111MODULE=“”
7 | GOARCH=“amd64” 8 | GOBIN=“” 9 | GOCACHE=“/root/.cache/go-build” 10 | GOENV=“/root/.config/go/env” 11 | GOEXE=“” 12 | GOFLAGS=“” 13 | GOHOSTARCH=“amd64” 14 | GOHOSTOS=“linux” 15 | GOINSECURE=“” 16 | GONOPROXY=“” 17 | GONOSUMDB=“” 18 | GOOS=“linux” 19 | GOPATH=“/go” 20 | GOPRIVATE=“” 21 | GOPROXY=“direct,https://goproxy.cn” 22 | GOROOT=“/usr/local/go” 23 | GOSUMDB=“sum.golang.org” 24 | GOTMPDIR=“” 25 | GOTOOLDIR=“/usr/local/go/pkg/tool/linux_amd64” 26 | GCCGO=“gccgo” 27 | AR=“ar” 28 | CC=“gcc” 29 | CXX=“g++” 30 | CGO_ENABLED=“1” 31 | GOMOD=“” 32 | CGO_CFLAGS=“-g -O2” 33 | CGO_CPPFLAGS=“” 34 | CGO_CXXFLAGS=“-g -O2” 35 | CGO_FFLAGS=“-g -O2” 36 | CGO_LDFLAGS=“-g -O2” 37 | PKG_CONFIG=“pkg-config” 38 | GOGCCFLAGS=“-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build354326419=/tmp/go-build -gno-record-gcc-switches”
What did you do?
$ get -u github.com/mgechev/revive
unrecognized import path "golang.org/x/tools/go/gcexportdata": https fetch: Get "https://golang.org/x/tools/go/gcexportdata?go-get=1": net/http: TLS handshake timeout
What is the behavior of the bug?
a TLS handshake timeout
Do you have any guesses?
sory I dont.
Sory I dont. But I’m waiting to have this fixed about 17 days … the revive tool is used in gitea’s go-sdk CI: https://drone.gitea.com/gitea/go-sdk
the CI task with env info: https://drone.gitea.com/gitea/go-sdk/483/1/3 normal CI task witch is failing: https://drone.gitea.com/gitea/go-sdk/474/1/3
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (9 by maintainers)
BTW, I think I need explain to you how Go modules work in your scenario.
When the
GOPROXYishttps://goproxy.cn:gocommand found that you need thegolang.org/x/tools/go/gcexportdatapackagegocommand does not know if thegolang.org/x/tools/go/gcexportdatais a module path (spoiler, it’s not, it’s just an import path)gocommand starts “module path estimation” based on yourGOPROXYsettinggocommand sent a Go module proxy request (https://goproxy.cn/golang.org/x/tools/go/gcexportdata/@v/list) and received a 404 responsegocommand trims the original import path togolang.org/x/tools/go(discard the last path element)gocommand send a Go module proxy request (https://goproxy.cn/golang.org/x/tools/go/@v/list) and received a 404 responsegocommand trims the original import path togolang.org/x/tools(discard one more last path element)gocommand send a Go module proxy request (https://goproxy.cn/golang.org/x/tools/@v/list) and received a 200 response with an empty bodygocommand send a Go module proxy request (https://goproxy.cn/golang.org/x/tools/@latest) and received a 200 response with an module info bodygocommand completes “module path estimation”When the
GOPROXYishttps://goproxy.cn,direct:gocommand found that you need thegolang.org/x/tools/go/gcexportdatapackagegocommand does not know if thegolang.org/x/tools/go/gcexportdatais a module path (spoiler, it’s not, it’s just an import path)gocommand starts “module path estimation” based on yourGOPROXYsettinggocommand sent a Go module proxy request (https://goproxy.cn/golang.org/x/tools/go/gcexportdata/@v/list) and received a 404 responsegocommand falls back to thedirectyou specified in the GOPROXY comma listgocommand sent a traditionalgo getrequest (https://golang.org/x/tools/go/gcexportdata?go-get=1) and a timeout occurred due to the network of your CI servergocommand fails “module path estimation”So, you can see that if there is a request like
https://golang.org/x/tools/go/gcexportdata?go-get=1, then your relatedgocommand absolutely uses no proxy. Because if it uses a certain proxy, then this situation of going directly to the source will not occur, instead, all request URLs will begin with that proxy (like https://goproxy.cn/golang.org/x/tools/go/gcexportdata/@v/list).