go get explicit versions to avoid ambiguous imports

[nikhita]

Fixes #304

Ref: kubernetes/kubernetes#113366, kubernetes/kubernetes#114829

I haven't had the chance to do a test run of the bot to verify this but can reproduce this locally using:

1. Clone the https://github.com/kubernetes/kube-aggregator repo (the publishing-bot fails while publishing this repo).
2. Run go mod edit -require=golang.org/x/[email protected]. It's not an exact representation of what the bot does since it doesn't update k8s deps but it's enough to reproduce the error.
3. Run go mod tidy. We'll see a failure:

k8s.io/kube-aggregator/pkg/cmd/server imports
	k8s.io/apiserver/pkg/server/options imports
	k8s.io/apiserver/pkg/storage/storagebackend/factory imports
	go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc tested by
	go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc.test imports
	google.golang.org/grpc/interop imports
	golang.org/x/oauth2/google imports
	cloud.google.com/go/compute/metadata: ambiguous import: found package cloud.google.com/go/compute/metadata in multiple modules:
	cloud.google.com/go v0.97.0 (/Users/nraghunath/go/pkg/mod/cloud.google.com/[email protected]/compute/metadata)
	cloud.google.com/go/compute/metadata v0.2.0 (/Users/nraghunath/go/pkg/mod/cloud.google.com/go/compute/[email protected])

4. Run go get cloud.google.com/[email protected] and then run go mod tidy again. It passes without an error.

Notes:

1. Even after this change is merged, if someone clones the repo they'll always be a need to run a go get cloud.google.com/[email protected] for go mod tidy to succeed (due to cmd/go: ensure that 'go mod tidy' and go get -u do not introduce ambiguous imports golang/go#27899).
2. Running a go get cloud.google.com/go/compute/[email protected] will also technically allow go mod tidy for kube-aggregator but it'll fail for apiserver becaue it has an explict require directive for cloud.google.com/[email protected].

This will be necessary until we bump cloud.google.com/go or remove dependency on it as mentioned in #304.

/hold
for review

/cc @dims @liggitt

[nikhita]

cc @skitt -- since you created googleapis/google-cloud-go#7209

[nikhita]

I haven't had the chance to do a test run of the bot to verify this

Verified for just publishing the master branch for kube-aggregator and it worked 👍

[dims]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, nikhita

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dims,nikhita]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[nikhita]

/hold cancel

[liggitt]

Hmm, I'm not sure we should do this… doesn't this change the versions the module is requiring?

[nikhita]

doesn't this change the versions the module is requiring

Yes, but it ends up being a no-op for repos (e.g kube-aggregator) that don't need to require cloud.google.com/go because go mod tidy will remove it from go.mod.

For repos that already require it (e.g. apiserver), they are already at v0.97.0 so it ends up being a no-op again.

[liggitt]

This still seems like something that shouldn't happen at this level, and will get stale or force the wrong version eventually on some branch

[skitt]

At least it could check that the current go.mod pulls in cloud.google.com/go, in a version older than v0.105.0 (if any); something like

if [ "$((go list -m -json cloud.google.com/go | jq -r '.Version'; echo v0.105.0) | sort -V | head -n 1)" != v0.105.0 ]; then

Or just re-get the currently-required version:

if [ -n "$(go list -m cloud.google.com/go)" ]; then go get "cloud.google.com/go@$(go list -m -json cloud.google.com/go | jq -r '.Version')"; fi