Closed michaelkedar closed 1 week ago
Attention: Patch coverage is 64.18605%
with 77 lines
in your changes missing coverage. Please review.
Project coverage is 68.30%. Comparing base (
1856add
) to head (91f842d
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
fwiw I've written up my thoughts on this on the issue - overall my main comment here is that I think it would be best to see if you can get the now-not-violated revive
rules enabled for these files/packages to prevent future regressions and to let us know what in these files still needs actioning via explicitly inline disables.
overall my main comment here is that I think it would be best to see if you can get the now-not-violated
revive
rules enabled for these files/packages to prevent future regressions and to let us know what in these files still needs actioning via explicitly inline disables.
I can't seem to work out good a way to only enable revive rules for specific files (apparently you can add an exclude:
do individual rules, but I can't get that to work.
Best I can do is add something like
issues:
exclude-rules:
- path-except: internal/(resolution|remediation|tui)/
linters:
- revive
But that's not great, and it'll disable the indent-error-flow
lint that we currently have enabled for everything else...
I can go disable the violating rules inline everywhere else, but tbh it'd be easier to fix most of the violations instead (and I wanted to limit the scope of this PR)
Helping with #1257 Changed the guided remediation code (
cmd/osv-scanner/fix
, andinternal/resolution
,remediation
andtui
) to fix lint errors found when usingrevive
's default settings. All of this is internal, so there's no API breakages.It was mostly
unexported-return
and stuttering complaints (e.g.resolution.ResolutionResult
->resolution.Result
), so a bunch of structs have been renamed.