-
Notifications
You must be signed in to change notification settings - Fork 329
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
Allow GOVERSION to be overridden #848
Labels
enhancement
New feature or request
Comments
#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:
Or rather, it would be:
|
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. |
hogo6002
added a commit
that referenced
this issue
Mar 11, 2024
fixes #848. Allow users to specify a `GOVERSION` other than the one in `go.mod` . Usage: in toml, `GoVersionOverride = "1.21.0"`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: