clusterctl: make clusterctl be available via go install

[sivchari]

What steps did you take and what happened?

related with #11464

Currently, clusterctl is unavailable via go install since a following error is occurred.

$ kind create cluster --name quick
Creating cluster "quick" ...
 ✓ Ensuring node image (kindest/node:v1.27.3) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-quick"
You can now use your cluster with:

kubectl cluster-info --context kind-quick

Have a nice day! 👋

$ clusterctl init --infrastructure docker
Fetching providers
Installing cert-manager version="v1.16.1"
Waiting for cert-manager to be available...
Installing provider="cluster-api" version="v1.8.5" targetNamespace="capi-system"
Installing provider="bootstrap-kubeadm" version="v1.8.5" targetNamespace="capi-kubeadm-bootstrap-system"
Installing provider="control-plane-kubeadm" version="v1.8.5" targetNamespace="capi-kubeadm-control-plane-system"
Installing provider="infrastructure-docker" version="v1.8.5" targetNamespace="capd-system"

Your management cluster has been initialized successfully!

You can now create your first workload cluster by running the following:

  clusterctl generate cluster [name] --kubernetes-version [version] | kubectl apply -f -

Error: unable to verify clusterctl version: unable to semver parse clusterctl GitVersion: strconv.ParseUint: parsing "": invalid syntax

This error is that why the clusterctl isn't embed the some versions since the go install doesn't use ldflag.
To use go install is general way to install some binaries and this validation in clusterctl is only used to compare local version with latest version.
Since we can embed the these variables by providing the ldflags to the go install, I think it's better way to do comparison if these variables is set.
In additional, current comparison only check the patch version. So it doesn't suggest new clusterctl version when local clusterctl is vX.Y.Z and latest one is vX.Y+1.Z.
That's why, I think it's also better to fix this implementation.

What did you expect to happen?

Make clusterctl be available via go install.

Cluster API version

v1.8.5

Kubernetes version

No response

Anything else you would like to add?

No response

Label(s) to be applied

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

/area clusterctl

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[chrischdi]

Probably we should also prepare for golang/go#50603

/reopen

Maybe we should open a separate issue for this, but reopening here until we move to a different one.

[k8s-ci-robot]

@chrischdi: Reopened this issue.

In response to this:

Probably we should also prepare for golang/go#50603

/reopen

Maybe we should open a separate issue for this, but reopening here until we move to a different one.

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-sigs/prow repository.

[chrischdi]

/close

Makeing a note for myself to add it to the Kubernetes v1.33 Bump issue as soon as it exists (this contains our go bump)

[k8s-ci-robot]

@chrischdi: Closing this issue.

In response to this:

/close

Makeing a node for myself to add it to the Kubernetes v1.33 Bump issue as soon as it exists (this contains our go bump)

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-sigs/prow repository.