fix: version command fix

[james-milligan]

Possible fix for populating version variables when using go install
Signed-off-by: James-Milligan james@omnant.co.uk

[AlexsJones]

Does the "vcs.revision" print the short sha?

[james-milligan]

Does the "vcs.revision" print the short sha?

it does not, example output:

flagd 0.0.9 (40676e362da172315346db7ef7e5b97a0cabb319) built at 2022-08-19T13:14:24Z

[AlexsJones]

This seems to be slightly confusing, if its not "devel" version it will use the vcs.time value from the build info? What about the params in main?

[james-milligan]

The version key value from ReadBuildInfo() will currently read v0.0.9 if go install was used to install the binary, but will read (devel) if go get was used. This means that the priority is currently: go 1.18 build info => -ldflags => default values in main.

As for the remaining values (time and revision) I felt it fitting to pull these from the same data set as the version, so when version is set and not (devel) it'll use the vcs values.

[AlexsJones]

This isn't working as expected when producing a docker image

❯ docker run cnskunkworks/flagd:james-branch version

		 ______   __       ________   _______    ______
		/_____/\ /_/\     /_______/\ /______/\  /_____/\
		\::::_\/_\:\ \    \::: _  \ \\::::__\/__\:::_ \ \
		 \:\/___/\\:\ \    \::(_)  \ \\:\ /____/\\:\ \ \ \
		  \:::._\/ \:\ \____\:: __  \ \\:\\_  _\/ \:\ \ \ \
		   \:\ \    \:\/___/\\:.\ \  \ \\:\_\ \ \  \:\/.:| |
		    \_\/     \_____\/ \__\/\__\/ \_____\/   \____/_/

flagd  (5365272) built at 2022-08-22T15:59:00Z

The injected arg is --build-arg=VERSION="$$(git describe --tags --abbrev=0)"

which provides the tag locally on your repo of v0.0.1 which I created manually.

[james-milligan]

just looked into this and it seems the version value remains unset in this example, which is making me lose confidence in this as an approach, a simple fix would be to replace:
if ok && details.Main.Version != "(devel)" {
with
if ok && details.Main.Version != "" && details.Main.Version != "(devel)" {
but this is making it feel a little bloated which suggests it may not be the right way to be going about this.
what are your thoughts @AlexsJones

[AlexsJones]

Perhaps unless it's a downloaded release we compromise to say that go install will be

flagd dev (HEAD) built at unknown

if someone wants a supported version they download a release?

[james-milligan]

Personally I would feel more comfortable with a 'hacky' approach than to not provide a version at all on the go install binary.
Ive updated the priority order so that ReadBuildInfo() is more of a final check.

What are your thoughts @skyerus @beeme1mr @toddbaert

[AlexsJones]

I don't have a problem with the revised code now, this wasn't the case when we discussed it previously, so I am happy to accept it now...