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

[davecheney]

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.

[thepudds]

You have likely already seen this, but some chance related to #33513 (comment)

[bcmills]

Note the error text returned by that URL:

not found: k8s.io/client-go@v12.0.0+incompatible: invalid version: +incompatible suffix not allowed: module contains a go.mod file, so semantic import versioning is required

See https://tip.golang.org/doc/go1.13#version-validation for more detail and advice on fixes and workarounds.

[bcmills]

See also #32695.

[bcmills]

Duplicate of #32805

[thepudds]

FWIW, a bit more detail.

The v12.0.0 go.mod file for k8s.io/client-go appears to be missing the required /v12 at the end of the module line:

https://github.com/kubernetes/client-go/blob/v12.0.0/go.mod#L3

module k8s.io/client-go

From the cmd/go documentation

In semantic versioning, changing the major version number indicates a lack of backwards compatibility with earlier versions. To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2, and packages in that module would use that path as their import path prefix, as in example.com/m/v2/sub/pkg. Including the major version number in the module path and import paths in this way is called "semantic import versioning".

CC @liggitt @nikhita

[thepudds]

Some additional context is that proxy.golang.org was recently updated to use 1.13beta1, which included "invalidating some old module versions that are currently being served from proxy.golang.org but are no longer valid in 1.13".

Some more details from the one of the announcements on golang-dev:

As an update, related to https://golang.org/issue/32805 and https://golang.org/issue/32879#issuecomment-507861612:
Go 1.13 includes some changes to the go command which tighten up the validation of module versions. Now that we have upgraded proxy.golang.org to use the 1.13beta1 version of the go command, we will be invalidating old module versions that are currently being served from proxy.golang.org but are no longer valid in 1.13. We don't expect any major issues from users since the request count is low for each of the module versions that will be invalidated, but please file issues against the issue tracker, prefixed "proxy.golang.org", if you encounter any problems. Thanks to everyone who has filed issues so far and given us feedback!

[davecheney]

@bcmills i'm sorry to reopen this but this has broken our Go 1.12 builds, we're not in a position to upgrade to 1.13beta1. We need a solution that restores functionality for Go 1.12.

[bcmills]

@davecheney, a replace directive (as described in the 1.13 release notes) should also work in 1.12. Please give it a try.

[thepudds]

Two other potential options when using the Go 1.12 go command:

1. Use an alternate proxy. For example, this seemed to work just now, perhaps because goproxy.io is not yet running Go 1.13:

GOPROXY=https://goproxy.io go get -d k8s.io/client-go@v12.0.0

2. Use direct. This also seemed to work just now:

GOPROXY=direct go get -d k8s.io/client-go@v12.0.0

[davecheney]

@bcmills this worked last week. Our builds built last week using Go 1.12. They worked on Monday. Something has broken in proxy.golang.org that means it no longer works as it did just a few days ago.

It's unreasonable to ask users to change their go.mod configuration because proxy.golang.org can no longer serve valid artefacts that it served a few days ago.