6

I want to add the current git revision number to the the binary built by go build so that I can do something like ./mybinary --revision to see which revision it is built from (usually for troubleshooting later on after deployment).

Obviously I cannot put the revision number into the source since that will change the source with a new revision.

I'm wondering if there is any other way to do this?
Or do you think this is just a bad idea? If so, what's the recommended way to establish the relation between built binaries and its source version?
Version numbers do not seem to be a good idea with a distributed version control system.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Rio
  • 1,877
  • 3
  • 25
  • 25
  • 2
    Useful reading [Is it a good practice to make a tag in git for every deployment build?](http://stackoverflow.com/questions/13494637/is-it-a-good-practice-to-make-a-tag-in-git-for-every-deployment-build) [Enable ident string for Git repos](http://stackoverflow.com/a/1796675/960558) [How to auto-generate a version string in git](http://stackoverflow.com/questions/14673007/how-to-auto-generate-a-version-string-in-git) – Lazy Badger Mar 29 '13 at 23:06
  • That is a lazy answer, @LazyBadger. You are truly honoring your name. – vonbrand Mar 30 '13 at 02:14

5 Answers5

10

If you can get the git revision into $VERSION and have a variable named version (type string) in your main package, you can set it during the build with:

#!/bin/sh
VERSION=`git rev-parse --short HEAD`
go build -ldflags "-X main.version=$VERSION"  myfile.go
Michiel Roos
  • 863
  • 11
  • 13
topskip
  • 16,207
  • 15
  • 67
  • 99
6

The normal process should no longer involve any ldflags, starting with Go 1.18 (Q4 2021/Q1 2022).

See issue 37475 and CL 356013

The go command now embeds version control information in binaries including the currently checked-out revision and a flag indicating whether edited or untracked files are present.

Version control information is embedded if the go command is invoked in a directory within a Git or Mercurial repository, and the main package and its containing main module are in the same repository.
This information may be omitted using the flag -buildvcs=false.

Additionally, the go command embeds information about:

  • the build including build and tool tags (set with -tags),
  • compiler,
  • assembler, and
  • linker flags (like -gcflags),
  • whether cgo was enabled, and if it was, the values of the cgo environment variables (like CGO_CFLAGS).

This information may be omitted using the flag -buildinfo=false.

Both VCS and build information may be read together with module information using:

  • go version -m file or
  • runtime/debug.ReadBuildInfo (for the currently running binary) or
  • the new debug/buildinfo package.

CL 373875 adds

  • The BuildInfo struct has new fields with additional information about how the binary was built.
  • The new GoVersion field holds the version of Go used to build the binary.
  • The new Settings field is a slice of BuildSettings structs holding key/value pairs describing the build.
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

I'd create a version.go file with a single var version string and then process that before a call to go build and reset it after. In other words, go doesn't support any type of code generation so you'll need to rely on something external to do this.

dskinner
  • 10,527
  • 3
  • 34
  • 43
  • This is useful to handle semantic versioning via git tags. One option to alter version.go is with sed: `sed -i 's/var Version = .*/var Version = "'$(git describe --always)'"/' path/to/version.go` – J. Pelaez Jan 13 '23 at 14:01
1

For all and any versioned in Git code most obvious way for getting identification-string for any changeset (while I leave to you task of displaying this string on --revision options) is

  • using (at least sporadically) tags
  • git describe (with relevant options) on build stage
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
0

You would generally use tags (also known as labels in other version control systems) to note the files that make up a particular build. http://git-scm.com/book/en/Git-Basics-Tagging. I typically make tags that include the version and build date. For example v1.2_29Mar2013. If I have several products that can be built from the same code base I'll include something to identify which product.

Mark
  • 452
  • 2
  • 9