go: proxy.golang.org returning 410 for k8s.io/client-go@v12.0.0+incompatible

proxy.golang.org has stoped returning the correct result for k8s.io/client-go v 12.0.0

(~/devel/tttt) % cat go.mod 
module whatever

go 1.12

require k8s.io/client-go v12.0.0+incompatible // indirect
(~/devel/tttt) % env GOPATH=$(mktemp -d) GOPROXY=https://proxy.golang.org go1.12 get -x k8s.io/client-go@v12.0.0+incompatible
go: finding k8s.io/client-go v12.0.0+incompatible
go: k8s.io/client-go@v12.0.0+incompatible: unexpected status (https://proxy.golang.org/k8s.io/client-go/@v/v12.0.0+incompatible.info): 410 Gone
go: error loading module requirements

Note: the env GOPATH... is to avoid having to sudo rm -rf my $HOME/pkg/mod directory.

This was working on Friday and has broken our CI.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 37 (32 by maintainers)

Commits related to this issue

Most upvoted comments

Sorry if my comment is not related on this issue.

https://github.com/mattn/go-sqlite3/issues/755

Last year, in go-sqlite3, topic branch v2.0.0 was created to ready to make new release. Unfortunately, v2.0.0 was not merged. https://github.com/mattn/go-sqlite3/pull/611

So I removed the topic branch with git push origin :v2.0.0 but proxy.golang.org return https://proxy.golang.org/github.com/mattn/go-sqlite3/@v/list

v1.9.0
v1.3.0
v1.7.0
v1.8.0
v1.6.0
v1.0.0
v1.12.0
v1.5.0
v2.0.0+incompatible
v1.10.0
v1.11.0
v1.4.0
v1.2.0
v1.1.0

Is there any other way to solve this problem without releasing v2.0.1 of go-sqlite3 ?

Note) we did not make git tag v2.0.0

One other possible solution is I think 1.12 can be forced to use a pseudo-version with a commit hash corresponding to the v12.0.0 tag of k8s.io/client-go.

In particular, this works:

GOPROXY=https://proxy.golang.org go get -d k8s.io/client-go@78d2af7

with this result recorded in go.mod:

require k8s.io/client-go v0.0.0-20190620085101-78d2af792bab

78d2af792bab is the commit hash for v12.0.0 of client-go.

An alternative path to a similar result:

echo 'replace k8s.io/client-go => k8s.io/client-go 78d2af7' >> go.mod
go list -m all

which then results in a go.mod with:

replace k8s.io/client-go => k8s.io/client-go v0.0.0-20190620085101-78d2af792bab

What is the short-term solution ? Go 1.14 is not yet released. Is it possible to purge the proxy.golang.org cache ?

k8s.io/client-go@v12.0.0+incompatible is referred by 130 go module versions and what it means is that their builds will be broken unless they set the GOPROXY to https://gocenter.io. We will continue to serve this version. This specific version was downloaded a lot of times (in thousands) from GoCenter. More details here - https://search.gocenter.io/k8s.io~2Fclient-go/info?version=v12.0.0%2Bincompatible

Correct.

ahh, ok. Thanks for explaining. So the rules for +incompatible are:

  1. if the module does not have a go.mod file and has a sevmer tag above v1, then it is ok to list it as +incompatible. (I’m assuming the go tool, or the proxy, strips off the +incompatable at some point)
  2. If the module does have a go.mod file and has a semver tag above v1 but does not conform to SIV, then the module cannot be referred to as +incompatible, the importer must fall back to the v0 pseudo version.