You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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=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.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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 🤔
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=env
means that the environment variablesGO_VCS
,GO_VCS_REVISION
,GO_VCS_TIME
andGO_VCS_MODIFIED
will be used to populatevcs
,vcs.revision
,vcs.time
, andvcs.modified
, respectively.External file
-buildvcs=metadata.json
means 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=json
is 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.The text was updated successfully, but these errors were encountered: