-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🌱 Enable excluded lint checks #4624
Conversation
Hi @stmcginnis. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@@ -38,10 +38,17 @@ linters: | |||
issues: | |||
max-same-issues: 0 | |||
max-issues-per-linter: 0 | |||
exclude-use-default: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about adding a comment here:
We are disabling default golangci exclusions because we want to help reviewers to focus on reviewing the most relevant changes in PRs and not too much on nitpicking.
.golangci.yml
Outdated
- Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*print(f|ln)?|os\.(Un)?Setenv). is not checked | ||
- (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form) | ||
- Subprocess launch(ed with variable|ing should be audited) | ||
- (G104|G307) | ||
- (Expect directory permissions to be 0750 or less|Expect file permissions to be 0600 or less) | ||
- package comment should be of the form "Package (.+) ..." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to restructure this a bit so we group
- Default golangci exclusions that we would like to remove as soon as possible
- Default golangci exclusions that we preserve (possibily explaining why)
- Additional exclusions that we added in CAPI (possibily explaining why)
Also, in the golangci doc I see exclusions being numbered; what about preserving this number inner comments ?
/ok-to-test |
There are a set of lint checks that are disabled by default with golangci-lint. This enables them by setting exclude-use-default to false. This by itself triggers a set of lint failures due to these additional checks. To by systematic about addressing these potential issues, this adds those checks back as individual exclusions so they can be addressed on by one. This eliminates one of those individual checks by addressing cases of "Potential file inclusion via variable" where passed in variables are used in os.OpenFile calls. Signed-off-by: Sean McGinnis <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
# List of regexps of issue texts to exclude, empty list by default. | ||
exclude: | ||
- Using the variable on range scope `(tc)|(rt)|(tt)|(test)|(testcase)|(testCase)` in function literal | ||
- "G108: Profiling endpoint is automatically exposed on /debug/pprof" | ||
- Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*print(f|ln)?|os\.(Un)?Setenv). is not checked |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we want to get rid of a few of them. not the ones about fmt.Fprintf
, but e.g. File.Close()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, file.Close() in a defer is actually useful. While ignoring the error can be odd, if a file cannot be closed (because it's a syscall) an error is usually thrown way earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, missed your comment above. Then it's fine for me.
Just had a few of those when close failed when writing to S3/GCS and it's pretty hard to debug. But we also have "manual" reviews, so we should be good
- Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*print(f|ln)?|os\.(Un)?Setenv). is not checked | ||
# The following are being worked on to remove their exclusion. This list should be reduced or go away all together over time. | ||
# If it is decided they will not be addressed they should be moved above this comment. | ||
- (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stmcginnis That's the one which would detect these kinds of error right? https://github.com/kubernetes-sigs/cluster-api/pull/4607/files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I believe so. Next in the list to tackle. ;)
@@ -38,10 +38,21 @@ linters: | |||
issues: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some additional ideas for linters:
- exportloopref: checks for pointers to enclosing loop variables (https://github.com/kyoh86/exportloopref)
- gci: Gci control golang package import order and make it always deterministic. (https://github.com/daixiang0/gci)
- would help to enforce imports in 3 groups: sdk, external, local (i.e.
goimports --local
) (if we want that)
- would help to enforce imports in 3 groups: sdk, external, local (i.e.
- gofumpt: Gofumpt checks whether code was gofumpt-ed. (https://github.com/mvdan/gofumpt)
- slightly more opinionated than gofmt (over time I found it pretty much matches my own preferences :))
- ifshort: Checks that your code uses short syntax for if-statements whenever possible (https://github.com/esimonov/ifshort)
- nilerr: Finds the code that returns nil even if it checks that the error is not nil. (https://github.com/gostaticanalysis/nilerr)
ref: https://golangci-lint.run/usage/linters/
Just some ideas. I don't want to start a lengthy discussion like tab vs spaces :). But if we get consensus on one / a few of them, that would be nice.
If we want them, they should probably be added commented out here and then introduced one at a time (like with the exclude
below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on exportloopref, ifshort, and nilerr
The others require new tooling that are more stylistic than not, which I'm generally fine to leave as is
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Timeouts that shouldn't be related. |
What this PR does / why we need it:
There are a set of lint checks that are disabled by default with
golangci-lint. This enables them by setting exclude-use-default to
false.
This by itself triggers a set of lint failures due to these additional
checks. To by systematic about addressing these potential issues, this
adds those checks back as individual exclusions so they can be addressed
on by one.
This eliminates one of those individual checks by addressing cases of
"Potential file inclusion via variable" where passed in variables are
used in os.OpenFile calls.
Which issue(s) this PR fixes:
Related #4622