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 fix in #818 appears to block the ability to specify a GOVERSION other than the go.mod value. In my own scenario, I deploy a library with associated binaries, compile the binaries with the latest version of Go, but leave the go.mod a few releases back to avoid forcing an upgrade on anyone importing the library. Would it be possible to default to GOVERSION if it is defined, or to give a configuration option to allow injecting a version to use?
The text was updated successfully, but these errors were encountered:
#850 seems to take an osv-scanner configuration specific approach, which is fine, but is there any value in also supporting the Go native way of doing things via a toolchain directive (if present)?
I assume precedence (from highest to lowest) would go:
config override
toolchain directive (if present and newer than go directive)
go directive
Or rather, it would be:
config override
the go stdlib version detected in the go.mod, taking toolchain into account
That sounds reasonable to me, no need to block #850 for this change, but let's keep this issue open until we add a tool chain version extraction as well.
The fix in #818 appears to block the ability to specify a
GOVERSION
other than thego.mod
value. In my own scenario, I deploy a library with associated binaries, compile the binaries with the latest version of Go, but leave thego.mod
a few releases back to avoid forcing an upgrade on anyone importing the library. Would it be possible to default toGOVERSION
if it is defined, or to give a configuration option to allow injecting a version to use?The text was updated successfully, but these errors were encountered: