Add version subcommand

[invidian]

I've tried to upload a record for my software for testing and I had some issues. I installed rekor using go get -u -v github.com/sigstore/rekor/cmd/cli.

When I pulled the repository and rebuild the binary, everything worked.

It would be nice if --version or version subcommand (ideally both, aliased) could be implemented, so one can quickly check what version it's running. Even though for go get installations it will be difficult to get reasonable version without tagged release.

[lukehinds]

Good idea.

You would be on master here so there is not version as such, but when roll a release we could likely use the tag

[endorama]

I'd be willing to contribute on this.

What I generally do on Go project is an internal package version with globals (version and commit) that get replaced at build time with go build -X. The version string can then be printed from a version command or --version flag on the rootCmd.

Would that be ok? On master the version would look like master (built from 00aabbcc).

Questions:

1. I'm not sure how to handle the go get case and if it's in scope for this issue
2. as this project has a server and client CLIs, how are expected to be versioned? Should the version be the same at each release?
3. is Implement a version flag #219 a duplicate or do you want to track version subcommand and --version flag in 2 separate issues?

Thanks!

[invidian]

is #219 a duplicate or do you want to track version subcommand and --version flag in 2 separate issues?

Seems like a duplicate to me. I think there should be either version or --version. Or both aliased to the same code. I personally like -v --version the most as it's the most predictable.

I'm not sure how to handle the go get case and if it's in scope for this issue

I usually put a static string in the package for tags (so v0.1.0 and v0.2.0-unreleased) and bump them during the release process, so you don't have to rely on build environment. It's not ideal, but I don't think there is a better way right now. But I think this is the case which would be very nice to have.

[lukehinds]

sorry, the dupe was my fault, closed that now

would be good if you could take this on @endorama

I will defer to @dlorenc on how best to implement as he has a better grasp of go idioms than myself.

[lukehinds]

@endorama I pinged you on slack about something

[hectorj2f]

@lukehinds isn't this done?

[invidian]

I see version subcommand now.

Just a note, it's not very useful when you install via go install -v github.com/sigstore/rekor/cmd/rekor-cli@latest, mentioned in https://github.com/sigstore/rekor/blob/main/INSTALLATION.md#using-go-install, as it produces the following output:

$ rekor-cli version
GitVersion:    unknown
GitCommit:     unknown
GitTreeState:  unknown
BuildDate:     unknown
GoVersion:     go1.16.6
Compiler:      gc
Platform:      linux/amd64

😄

[hectorj2f]

@invidian have you tried with the latest release?

[invidian]

@invidian have you tried with the latest release?

Well, latest fetches the latest tag according to Go modules selection.

I've tried the release binary and it of course works as expected.

[hectorj2f]

Perhaps it should show the commit hash as version unless it is a tagged one.

[cpanato]

@invidian @hectorj2f the GitVersion/GitCommit /GitTreeState/BuildDate are injected during the build time via LDFlags, Honestly, I don't know how to inject that when you use go install... there is a way to do that?

otherwise, maybe we can hardcode those to be something like dev if we don't set the variables, WDYT?

[invidian]

I know that some projects, have latest tag + -dev suffix, which gets touched before every release, This makes go get or go install have the right tag then at least.