-
Notifications
You must be signed in to change notification settings - Fork 18.5k
Description
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:
-
Environment variables
-buildvcs=envmeans that the environment variablesGO_VCS,GO_VCS_REVISION,GO_VCS_TIMEandGO_VCS_MODIFIEDwill be used to populatevcs,vcs.revision,vcs.time, andvcs.modified, respectively. -
External file
-buildvcs=metadata.jsonmeans that the filemetadata.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=jsonis better, with a fixed filename. -
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status