go get / go install for projects depending on capi does not work

[enxebre]

What steps did you take and what happened:

go install sigs.k8s.io/[email protected]: sigs.k8s.io/[email protected]
	The go.mod file for the module providing named packages contains one or
	more replace directives. It must not contain directives that would cause
	it to be interpreted differently than if it were the main module.
Albertos-MacBook-Pro:~@albertogarla $ go get sigs.k8s.io/[email protected]

go get: sigs.k8s.io/[email protected] updating to
	sigs.k8s.io/[email protected] requires
	sigs.k8s.io/cluster-api/[email protected] requires
	sigs.k8s.io/[email protected]: invalid version: unknown revision 000000000000

go get: sigs.k8s.io/cluster-api/test@none updating to
	sigs.k8s.io/cluster-api/[email protected] requires
	sigs.k8s.io/[email protected]: invalid version: unknown revision 000000000000

What did you expect to happen:
go get / go install works

Anything else you would like to add:
This is the controversial clause https://github.com/kubernetes-sigs/cluster-api/blob/master/test/go.mod#L5
This can be workaround by adding a replace clause for capi in the invoking go.mod file. Nevertheless I'd expect us to provide a better solution so this commands work out of the box.

Environment:

• Cluster-api version:
• Minikube/KIND version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[killianmuldoon]

adding a replace clause for capi in the invoking go.mod file

Can you expand on this?

Another solution I'm seeing is to avoid doing this for release versions of a project so that go install etc. will work for release versions but this easier method of testing the latest code can be used for whatever the local version is. c/f

[enxebre]

Can you expand on this?

Basically what any consumer needs to do today, e.g any provider https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/go.mod#L5

Another solution I'm seeing is to avoid doing this for release versions of a project so that go install etc. will work for release versions but this easier method of testing the latest code can be used for whatever the local version is. c/f

Sounds interesting. This should possible be pointing to a pinned version https://github.com/kubernetes-sigs/cluster-api/blob/v0.4.2/test/go.mod#L5

[killianmuldoon]

@fabriziopandini do you think we could update the release tools to pin this version for each release?

[vincepri]

@killianmuldoon What did you have in mind to do the above? The current release process happens after the tag is published

[killianmuldoon]

I was thinking maybe adding something to change this line in go.mod under 'make release' - but with the ordering there will be drift with the go.mod.

[vincepri]

/milestone Next

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[sbueringer]

/close
in favor of #6081

[k8s-ci-robot]

@sbueringer: Closing this issue.

In response to this:

/close
in favor of #6081

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.