Incorrect version values from version.Get()

[ffromani]

I vendored client-go v0.19.0 in my project.
I just fetch the version and log it on server startup, and I see something like

{"component":"kubevirt-template-validator","level":"info","msg":"kubevirt-template-validator using kubevirt client-go (v0.0.0-master+$Format:%h$ $Format:%H$ 1970-01-01T00:00:00Z)","pos":"app.go:77","timestamp":"2019-07-26T13:21:30.760879Z"}

I was expecting

• GitVersion [v]0.19.0
• GitCommit
• BuildDate a valid date

it seems these fields aren't properly set when the tag is cut.

[slintes]

How did you get that version? I assume with the version pkg? Well, it works as designed: the version package was designed to report the KubeVirt version, and values are set during the build process via ldflags. The values you see are the default values.
So even when you update your build process to set those values, it would report the version of your own component, and not client-go's version. Not sure if we can/want to support the latter. @rmohr wdyt?

You can get KubeVirt's server version if that helps:

virtClient, _ := kubecli.GetKubevirtClient()
info, _ := virtClient.ServerVersion().Get()

[rmohr]

Not sure if we can/want to support the latter.

Yep I don't think it makes much sense to support this.

@slintes can we exclude anything related to version from client-go, when we sync with staging?

[slintes]

can we exclude anything related to version from client-go, when we sync with staging?

I think just excluding something won't work (well, it wouldn't be nice at least imho). But we could refactor it to only keep the version.Info struct in client-go (it's used in kubecli for getting the server's version), and move everything else back to kubevirt.

[ffromani]

@slintes yep, you basically got it. Looks like I misunderstood the purpose of the version package in the client-go module.
I'd like a way to report (= print in the logs) the release of client-go which my binary has compiled in; I can think of few workarounds which don't require any change, so we can close this issue.

[slintes]

if you have a workaround which we could easily add to client-go, let us know 🙂

/close

[kubevirt-bot]

@slintes: Closing this issue.

In response to this:

if you have a workaround which we could easily add to client-go, let us know 🙂

/close

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.