internal/version: Adopt Go 1.18+ implementation

[timflannagan]

Description

This PR overhauls the pkg/version library:

• Removes several files that are cruft (e.g. enterprise, federation, etc.)
• Moves the package from pkg/ -> internal/
• Refactors the version package to be based on the Go 1.18+ version approach via runtime.ReadBuildInfo()
• Add the --version CLI flag to the controller binary to decorate the version.Version build flag with VCS metadata

See the Go 1.18 release notes for more information.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

[timflannagan]

I'm typically hesitant introducing new direct dependencies, but in this case cobra is pretty standard and I wasn't able to get to refactoring the CLI packages when we were pushing through the deflate/cleanup repository stream of work at the time.

[lgadban]

not opposed, but cobra here for a single binary startup (i.e. not a CLI) does seem a bit excessive.

also, we have the Settings replacement plumbed via env vars, if we are going cobra maybe we should reevaluate Viper for the env var config?

no real blocker here, just thinking out loud

[timflannagan]

Talked with Yuval about this offline: I was planning on refactoring the SDS/envoyinit cmd packages to use cobra to be consistent with the kgateway package as a follow-up when I have some downtime. In this case, we'd pipe configuration to our internal packages via cobra flags and expose knobs in the helm chart for higher-level config.

[timflannagan]

@lgadban Glossed over your "not a CLI" comment. IMHO, all these binaries should be CLI-based with the sole responsibility that they 1.) provide flags/configuration to libraries, 2.) call that libaries' constructor and delegate to that library to do the heavy lifting, and 3.) handle any I/O that doesn't make sense in the context of the library being utilized.

[yuval-k]

just tried it:

❯ ./_output/internal/kgateway/kgateway-linux-amd64 --version
controller version 1.0.1-dev, commit 8f82c9e3e37452bd4aacf70398251d76f330e374, built at 2025-02-17T23:20:27Z

looks good!

[timflannagan]

@yuval-k Perfect. Last I checked the controller will only log the version.Version variable, but we can adjust that the entire version.String() (which includes the VCS metadata) is logged too.

[lgadban]

Refactors the version package to be based on the Go 1.18+ version approach via runtime.ReadBuildInfo()

@timflannagan can you add a ref link to the PR description for above?

[timflannagan]

@lgadban Done, added a link to https://tip.golang.org/doc/go1.18#debug_buildinfo.

[lgadban]

very nice, just a quick discussion point

[lgadban]

not opposed, but cobra here for a single binary startup (i.e. not a CLI) does seem a bit excessive.

also, we have the Settings replacement plumbed via env vars, if we are going cobra maybe we should reevaluate Viper for the env var config?

no real blocker here, just thinking out loud