Add -version flag

[superfrink]

Added -version flag. Exits non-zero so accidentally running with this flag will not indicate a service is up.

Typical output:

$ ./grpc-health-probe -version
git b35a00f4192e0a0654c9e1ff6e7400513e2d000a 2023-06-13T04:13:12Z

When built when there are local changes not checked into Git:

$ ./grpc-health-probe -version
git 1089f40639043ee46cc47cbea1bcb0cc48cfc284 2023-06-12T16:41:19Z (built with changes outside version control)

When not built with VCS information:

$ go run main.go -version
vcs info was not included in build
exit status 5

Note, Go does not include the Git tag in the build information included in the executable. If we want to do something like that, in the past I have had a build job run a script that runs git commands and writes the output into strings in a .go file that gets included in the build.

Fixes #14.

[ahmetb]

I prefer to maintain less code if possible. Can you instead use "go version -m BINARY"?

[superfrink]

Yes, that works if you have go inside the container. Do you want to close #14?

[superfrink]

I often prefer having a list of keys instead of long if ... else if ... structures and multiple variables. In this case where all we want is the commit hash and dirty status the code can be simplified by removing the vcsDetails map.

[superfrink]

The GoReleaser build for windows arm64 failed. The error is cgoAvailable is redeclared. go/src/net/cgo_stub.go has

// cgoAvailable set to false to indicate that the cgo resolver
// is not available on this system.
const cgoAvailable = false

and go/src/net/lookup_windows.go has:

// cgoAvailable set to true to indicate that the cgo resolver
// is available on Windows. Note that on Windows the cgo resolver
// does not actually use cgo.
const cgoAvailable = true

On a Linux machine it appears to build manually:

$ GOOS=windows GOARCH=arm64 go build
go: downloading github.com/Microsoft/go-winio v0.6.1

$ file grpc-health-probe.exe
grpc-health-probe.exe: PE32+ executable (console) Aarch64 (stripped to external PDB), for MS Windows

I wonder if importing runtime/debug is causing this.

[ahmetb]

This might be the old version of goreleaser doing something wrong as well.

[superfrink]

The build logs show it's interpreting the go version 1.20 as 1.2. It seems to be using a release candiate 1.21.0-rc2 instead of 1.2 or 1.20.

Run actions/setup-go@v1
with:

...

  go-version: 1.2

...

env:
  GOROOT: /opt/hostedtoolcache/go/1.21.0-rc2/x64

I wrapped the 1.20 in single quotes. That seems to work.

[ahmetb]

Good catch this probably broke during 1.19 → 1.20 and we probably built a few releases with go1.2 by mistake.

[superfrink]

I wonder if this is a new issue in the 1.21 rc? Just a guess. When I built it manually on the command line I used 1.20.5.

I just went back through the actions logs to find the latest that succeeded. It seems to have interpreted 1.20 as 1.20.5. https://github.com/grpc-ecosystem/grpc-health-probe/actions/runs/5308777585/jobs/9608631371