ci: pin the versions of govulncheck and gosec - #17
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
govulncheckandgosecwere installed with@latest, so the version moved on its own. A release of the tool turned a green run red with no change here.This is what happened to
keyratetoday. gosec published v2.28.0, which needs Go 1.25.8, and the workflow runs the Go version ingo.mod:The daily run passed on the 9th through the 12th and stopped on the 13th, with nothing changed in this repository.
The change
Both tools are pinned:
govulncheck@v1.7.0gosec@v2.28.0GOTOOLCHAIN=autois set on the install commands, and only there.actions/setup-gosetsGOTOOLCHAIN=local, which stops Go from fetching the toolchain a tool asks for. Withautoon that one command, Go fetches what it needs to build the tool, and the module is still read with the version ingo.mod.The alternative was to raise the
godirective of this module. That asks the same of everybody who imports it, for the sake of a scanner, so it is not the right lever.Verified
Reproduced the failure and the fix outside CI:
Dependabot does not watch a version inside a
run:step, so these move when you move them.