Add GO_LDFLAGS for Golang binary build information

[ariefrahmansyah]

Signed-off-by: Arief Rahmansyah [email protected]

[ariefrahmansyah]

#1709

[ariefrahmansyah]

The output will be like this:

level=info ts=2019-10-23T13:03:02.776071Z caller=main.go:72 msg="Starting Cortex" version="(version=0.3.0, branch=master, revision=b80d1f615fc7ed1c331d98f9228fb0e30f6a3b9a)"

Notes:

1. GIT_BRANCH instead of /tools/image-tag@master, because image-tag produces branch_name-git_revision[-WIP] while we only need branch name.

2. I keep VERSION file. I agree that the VERSION file value is often not in sync with the commit. But we still can refer to it, since it's must be bumped for every release to keep it in sync.

[bboreham]

GIT_BRANCH instead of /tools/image-tag@master, because image-tag produces branch_name-git_revision[-WIP] while we only need branch name.

To me, the WIP part can be very interesting.
40 chars of revision is not; 12 or 16 is plenty.

[bboreham]

Am I reading this right: you now have short commit sha in the 'branch' field, and long sha in 'revision' ?

Is this what anyone wants?

[pstibrany]

Note that this will break in Go 1.14, which will use vendor directory by default, if present and go.mod specifies go 1.14. Vendored dependencies need to be specified as github.com/cortexproject/cortex/vendor/github.com/prometheus/common/version :-(

I think easiest solution to handle both scenarios is to have simple build.go in the Cortex project, that will then set Prometheus values in init method.

[pracucci]

@ariefrahmansyah Are you still interested into this PR? If so, I would suggest you to rebase master and reiterate based on the received feedback.

[pracucci]

I'm going to close this PR due to inactivity. Feel free to reopen it in case you're still interested into working on this.