controller-gen cannot be properly versioned without patching the existing code

[josvazg]

The version computing code assumes the usage of the controller-gen will always be as a module:

$ go get github.com/controller-tools/cmd/[email protected]

Moreover, downloading the official released binaries from this repo directly they still render (devel)as the binary version.

This is not CI or reproducible environment friendly. Ideally, you would define your dependency version on some file, then just have it available in your environment.

Using the module approach and updating your go.mod does not make the binary available after go mod tidy, so the CI will not be able to use controller-gen.

There is no ready available packaging such as with brew or Debian.

Reproducible builds with versioning exist from nix, by patching the versioning code in this repository.

Given than using the CLI generator tool as a module is not natively supported by Go, and that a binary distribution of some kind is required, we would like to propose the following change.

• Use the industry standard way to set a version with ldflags, for instance -X sigs.k8s.io/controller-tools/pkg/version.Version=X.Y.Z
• When Version is not an empty string, override the usual return info.Main.Version with such local Version value.
• Change the builds to set the version at compile time, so official releases will render their correct version.

We are ready to follow up with a patch for this.

[s-urbaniak]

cc @vincepri

[s-urbaniak]

and cc @sbueringer 🙏

[sbueringer]

@josvazg @s-urbaniak Thx for opening the issue. I missed checking for the version when implementing the binary releases.

Proposal sounds good to me, feel free to open a PR

[josvazg]

Thanks @sbueringer !

Just posted #1049

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[josvazg]

Fix merged, we can close this now