ci: stop the Go lint step verifying its config over the network - #7022
Merged
Conversation
golangci-lint-action defaults to verify: true, which runs `golangci-lint config verify` before linting. That command fetches the schema from golangci-lint.run and has no offline mode: there is no --schema flag, and a $schema key in the config is rejected as an unknown property. So every push made four requests to a third-party host, one per matrix leg, on the path that gates merges. When one timed out, QA went red on master with no finding in any file (run 33672076496). What the check caught that linting does not is a misspelled or unknown top-level key: viper ignores those, so the block reads as configuration and configures nothing. `golangci-lint run` still refuses to start on the other two failure modes on its own - an unknown linter name and a YAML syntax or type error both abort it before analysis. That leaves a narrow gap, and it is worth naming rather than pretending otherwise. It is accepted here because the config changes rarely, a typo in it is not urgent, and the alternative was letting an external host decide whether master is green.
|
Claude finished @otavio's task in 20s —— View job Code Review CompleteReviewed 1 file across code quality, security, testing, language patterns, and architecture — no new issues found. The code looks good as-is.
To request another review round, comment |
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.
golangci-lint-actiondefaults toverify: true, which runsgolangci-lint config verifybeforelinting. That command fetches its JSON schema from
golangci-lint.runand has no offline mode —there is no
--schemaflag, and a$schemakey in the config is rejected as an unknown property.So every push made four requests to a third-party host, one per matrix leg, on the path that gates
merges. On run 33672076496 one
timed out and QA went red on master:
The linter never ran. No
.gofile was analysed.What this gives up
Tested against the real
.golangci.yamlwith v2.11.3:golangci-lint runconfig verifycan't load configcan't read viper configlinterz:)additional properties not allowedOnly the third row is lost.
runaborts on the other two by itself, so those stay covered.The gap is real: viper ignores keys it does not recognise, so a misspelled block reads as
configuration and configures nothing. It is accepted because the config changes rarely, a typo in
it is not urgent, and the alternative was letting an external host decide whether master is green.
If the gap starts to matter, the fix is a scheduled job running
config verifyon its own — offthe merge path, where an outage costs nothing.