Add build-time information as metric and in logs

[bluecmd]

We should expose what git commit was used to build the currently running exporter, as well as any tag associated with it. That way it is easier to reason about what version was running both in the logs and in metrics.

[secustor]

We should add this to the /metrics endpoint.
To ensure we have a tag in any case, we could use something like sematic-release. This would also solve a part of #38 as this would allow us to auto tag and build containers.

[bluecmd]

I have been looking into if there are some ways these days to include version information in the binaries without using ldflags or go generate. My biggest issue with those mentioned approaches are that they require a special build step, as opposed to just using "go build" or "go install".

What I have arrived at is that runtime/debug.BulldInfo is almost exactly what we are looking for - with a caveat. Due to golang/go#29228 any build using the normal "go build" will be tagged with just "(devel)".

For an example, check out https://github.com/mark-rushakoff/debug-module-version-demo.

[stereolith]$ go install github.com/mark-rushakoff/debug-module-version-demo@v0.0.1
[stereolith]$ go/bin/debug-module-version-demo
github.com/mark-rushakoff/debug-module-version-demo version v0.0.1
        built with golang.org/x/text version v0.0.0-20170915032832-14c0d48ead0c
        built with rsc.io/quote version v1.5.2
        built with rsc.io/sampler version v1.3.0

So for us that would mean that you could go install the fortigate_exporter at a certain version and we could pick up that version. That would be a neat recommended way to install the latest version.

Then we could also add a Makefile to aid people wanting to use a "go build"-like flow to create a version such as v1.0.2+abcdef1234 / v1.0.2+abcdef1234-dirty. Using that would be optional and if you just build with the classical go build you would just end up with a version tag of "v0.0.0-devel" as a fallback (as go build do not include any useful version information as per the linked bug above), for example.

What do you think @secustor?

EDIT: Long-term we can adopt golang/go#37475 as well.

[secustor]

I have been thinking about more in the ldflags direction.

The question from my point of view is, who will rely on this in the future? We are providing prebuild images and binaries, in which we can add versions as we see fit.

Therefore I think we should add the git SHA and tag during the build step of the binaries and something like this to our code so if somebody installs our package we can display informations.
https://github.com/burrowers/garble/pull/220/files#diff-2873f79a86c0d8b3335cd7731b0ecf7dd4301eb19a82ef7a1cba7589b5252261R253

[bluecmd]

🎉 This issue has been resolved in version 1.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀