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
I compile a binary with go. I distribute it. go, in its helpfulness, includes lots of information about modules and their versions, e.g. from dlv:
$ go version -m ./dlv
./dlv: go1.20.1
path github.com/go-delve/delve/cmd/dlv
mod github.com/go-delve/delve (devel)
dep github.com/cosiner/argv v0.1.0 h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg=
dep github.com/cpuguy83/go-md2man/v2 v2.0.0 h1:EoUDS0afbrsXAZ9YQ9jdu/mZ2sXgT1/2yyNng4PGlyM=
dep github.com/derekparker/trie v0.0.0-20221213183930-4c74548207f4
dep github.com/go-delve/liner v1.2.3-0.20220127212407-d32d89dd2a5d h1:pxjSLshkZJGLVm0wv20f/H0oTWiq/egkoJQ2ja6LEvo=
dep github.com/google/go-dap v0.6.0 h1:Y1RHGUtv3R8y6sXq2dtGRMYrFB2hSqyFVws7jucrzX4=
dep github.com/hashicorp/golang-lru v0.5.4 h1:YDjusn29QI/Das2iO9M0BHnIbxPeyuCHsjMW+lJfyTc=
...
Except for the module itself, which just shows (devel).
The compiled binary carries with it all of its dependency version and source information, but only package name for the root module itself. This makes it of much less usefulness for sbom and software supply-chain and provenance tools.
The build process populates BuildInfo, but leaves the version blank.
I recall seeing a discussion earlier about not wanting to depend on external tools; I get that. It might even be a good enough start if there were a "hook" that let you add that information, whether a flag or even the usual -X something=v1.2.3 (although calculating if it is a tag or a pseudo-version and what that is also appears not to be in an obviously exposed package).
Ideal: go build figures out, "I am running in a git repo at a specific commit, I will figure out my version or pseudo-version and put it in"
Below: go build provides an option to do it, something like --module-version=auto (to auto-populate) or --module-version=v1.2.3
Below: it provides a -X flag that can be used, e.g. -ldflags '-X runtime.BuildInfo.Version=v1.2.3', although that leaves it on the user to figure out what that version or pseudo-version is
The text was updated successfully, but these errors were encountered:
This is somewhat related to #44469
I compile a binary with go. I distribute it. go, in its helpfulness, includes lots of information about modules and their versions, e.g. from
dlv
:Except for the module itself, which just shows
(devel)
.The compiled binary carries with it all of its dependency version and source information, but only package name for the root module itself. This makes it of much less usefulness for sbom and software supply-chain and provenance tools.
The build process populates
BuildInfo
, but leaves the version blank.I recall seeing a discussion earlier about not wanting to depend on external tools; I get that. It might even be a good enough start if there were a "hook" that let you add that information, whether a flag or even the usual
-X something=v1.2.3
(although calculating if it is a tag or a pseudo-version and what that is also appears not to be in an obviously exposed package).go build
figures out, "I am running in a git repo at a specific commit, I will figure out my version or pseudo-version and put it in"go build
provides an option to do it, something like--module-version=auto
(to auto-populate) or--module-version=v1.2.3
-X
flag that can be used, e.g.-ldflags '-X runtime.BuildInfo.Version=v1.2.3'
, although that leaves it on the user to figure out what that version or pseudo-version isThe text was updated successfully, but these errors were encountered: