Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/go: add support for explicitly providing vcs metadata #64162

flimzy opened this issue Nov 15, 2023 · 2 comments

proposal: cmd/go: add support for explicitly providing vcs metadata #64162

flimzy opened this issue Nov 15, 2023 · 2 comments


Copy link

flimzy commented Nov 15, 2023

The addition of -buildvcs reduces the amount of boilerplate needed to track VCS metadata in binaries, but also adds a certain amount of overhead when building in limited environments (notably, within Docker containers). In particular, one must load .git (or other VCS directory/config) into the build context, and one must install their VCS tool of choice within the docker build environment.

I'd like to propose as a lighter-weight alternative we introduce -buildvcs option to directly provide the metadata key(s). This could take a few different forms. Three come to mind as potentially realistic:

  1. Environment variables

    -buildvcs=env means that the environment variables GO_VCS, GO_VCS_REVISION, GO_VCS_TIME and GO_VCS_MODIFIED will be used to populate vcs, vcs.revision, vcs.time, and vcs.modified, respectively.

  2. External file

    -buildvcs=metadata.json means that the file metadata.json* will be consulted, and expected to contain data in the form {"vcs":"git","revision":"860db4b0de1e5551871da59301d3cf5b41131cd6","time":"Wed Nov 1 09:14:15 2023 +0100","modified":false}

    *Format, and whether an arbitrary filename is allowed, are open for debate. maybe for e.g. -buildvcs=json is better, with a fixed filename.

  3. CSV on the command line

    -buildvcs="git,860db4b0de1e5551871da59301d3cf5b41131cd6,Wed Nov 1 09:14:15 2023 +0100,false" provides the metadata fields directly. Any omitted fields are ignored.

My personal preference is probably option 1, environment variables. It's probably the most directly compatible with Docker build environments (where I most care about this), and is also probably the least ambiguous and error-prone of the three.

Both option 1 and the fixed filename variant of option 2 have the potential to be triggered by -buildvcs=auto or -buildvcs=true as well, if the existing criteria for metadata detection are not met.

@gopherbot gopherbot added this to the Proposal milestone Nov 15, 2023
Copy link

bcmills commented Nov 15, 2023

The Go toolchain itself uses VERSION files. I wonder if we should codify that, since it is already something distributors of Go are likely familiar with.

@bcmills bcmills added the GoCommand cmd/go label Nov 15, 2023
Copy link

This seems useful. .git is almost always dockerignore-ed and VCS metadata in the go binary is super useful to debug stuff that's normally difficult to debug such as misconfigured CD pipelines that end up delivering the wrong binary to production.

I think environment variables only would be the best way to go, so there aren't multiple ways to do the same thing. And if one is in the context of building Dockers, one has control of the build command enough to create the relevant env vars.

I would also consider including the --decorated (at the time) - branch names and tag names (if applicable). While not super exact, it's normally very useful 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Status: Incoming

No branches or pull requests

4 participants