-
Notifications
You must be signed in to change notification settings - Fork 5.7k
chore(deps): Bump golangci-lint from v1.64.5 to v2.0.2 #16683
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
chore(deps): Bump golangci-lint from v1.64.5 to v2.0.2 #16683
Conversation
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.
Thanks for the bump @zak-pawel! Some comments in the code. I especially wonder why you move from require.Failf
to require.Fail(t, fmt.Sprintf(...))
... I prefer the former.
# Poorly chosen identifier. | ||
# https://staticcheck.dev/docs/checks/#ST1003 | ||
- -ST1003 | ||
# Incorrectly formatted error string. | ||
# https://staticcheck.dev/docs/checks/#ST1005 | ||
- -ST1005 | ||
# Should use constants for HTTP error codes, not magic numbers. | ||
# https://staticcheck.dev/docs/checks/#ST1013 | ||
- -ST1013 | ||
# Use consistent method receiver names. | ||
# https://staticcheck.dev/docs/checks/#ST1016 | ||
- -ST1016 | ||
# Don't use Yoda conditions. | ||
# https://staticcheck.dev/docs/checks/#ST1017 | ||
- -ST1017 | ||
# The documentation of an exported function should start with the function's name. | ||
# https://staticcheck.dev/docs/checks/#ST1020 | ||
- -ST1020 | ||
# The documentation of an exported type should start with type's name. | ||
# https://staticcheck.dev/docs/checks/#ST1021 | ||
- -ST1021 | ||
# The documentation of an exported variable or constant should start with variable's name. | ||
# https://staticcheck.dev/docs/checks/#ST1022 | ||
- -ST1022 | ||
# Apply De Morgan's law. | ||
# https://staticcheck.dev/docs/checks/#QF1001 | ||
- -QF1001 | ||
# Convert untagged switch to tagged switch. | ||
# https://staticcheck.dev/docs/checks/#QF1002 | ||
- -QF1002 | ||
# Convert if/else-if chain to tagged switch. | ||
# https://staticcheck.dev/docs/checks/#QF1003 | ||
- -QF1003 | ||
# Use 'strings.ReplaceAll' instead of 'strings.Replace' with 'n == -1'. | ||
# https://staticcheck.dev/docs/checks/#QF1004 | ||
- -QF1004 | ||
# Lift 'if'+'break' into loop condition. | ||
# https://staticcheck.dev/docs/checks/#QF1006 | ||
- -QF1006 | ||
# Merge conditional assignment into variable declaration. | ||
# https://staticcheck.dev/docs/checks/#QF1007 | ||
- -QF1007 | ||
# Omit embedded fields from selector expression. | ||
# https://staticcheck.dev/docs/checks/#QF1008 | ||
- -QF1008 | ||
# Use 'time.Time.Equal' instead of '==' operator. | ||
# https://staticcheck.dev/docs/checks/#QF1009 | ||
- -QF1009 |
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.
Which one of those are the ones that we should work on? All? Like if I want to do some linter work, which ones should I remove and work on the fallout? Could you please split this into two sections the "need to stay disabled" as we don't want them to run e.g. because we don't like what they enforce, and the "should be fixed" ones which we need to remove later.
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.
At the moment, all new findings from staticcheck
(so merged: staticcheck
, stylecheck
, and gosimple
) are disabled using a -
sign before the check name (e.g., -ST1017
means that the check for Don't use Yoda conditions.
is disabled).
My plan was to create a new issue for each of these disabled checks, where I would describe its functionality, list all findings, and discuss whether we want to enable it or not. Just like always :) I wanted to do this after merging this PR.
I could have explained this a bit more clearly in the PR description.
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.
OK, so all of them need to be tackled later? Like I was under the impression that we don't want to document exported function, at least not in plugins/
... Therefore, I thought e.g. ST1020
would be a candidate that stays disabled.. Am I mistaken here?
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.
Most likely, but I would continue this discussion in separate issues.
require.Positive(t, n, "expected migration application but none applied") | ||
require.NotZero(t, n, "expected migration application but none applied") |
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.
Hmmm that's something different, as e.g. -1
would error before but not now. However, I'm not sure if ApplyMigrations
returns an unsigned integer but in any case I would prefer the former as it is more informative and actually what we expect.
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 tried to workaround false positive finding here (useless-assert: meaningless assertion
).
Since this is uint64
, it will never be less than 0
.
But if you want, I can revert it to the previous state and add //nolint
with a false-positive description.
Let me know.
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 do understand but with Positive
you don't need to know if the result is signed or not, you do directly understand what we want. For NotZero
you need to know this is uint and cannot be negative. I also veto that useless-assert: meaningless assertion
is correct here! This is a bug!
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.
Back to Positive
with //nolint
. I will try to isolate this and fill the bug.
plugins/inputs/mock/mock_test.go
Outdated
require.Failf(t, "unexpected field %q", k) | ||
require.Fail(t, fmt.Sprintf("Unexpected field %q", k)) |
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.
Revert!
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 thought you might notice that 😜
I'll respond here once, but this applies to all comments related to require.Failxxx()
.
If I simply use require.Failf()
, then (in case of failure), the result will look like this:
Not very pretty, right? It's all because of the function signatures:
The versions with f
(FailNowf
and Failf
) require that the optional formatted string be the second string argument, not the first. The first one is mandatory and serves as the failureMessage
.
There are two options here:
-
Format the string using
fmt.Sprintf()
and pass it asfailureMessage
.
-
Provide a completely different string as
failureMessage
(but which one?), while passing the data needed for formatting as the third and fourth arguments.
As for preventing deferred functions from running: t.FailNow()
is called in every require.XXX
function when the condition is not met. And I guess defer
still gets executed 😉
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.
OK, in this case I opt for
require.Failf(t, "unexpected field", k)
I was not aware of this stupid behavior... 🤦
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.
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.
All require.Failxxx()
comments addressed: 357e548
require.FailNow(t, "no results returned from the counterPath: %v", len(hostCounters.counters)) | ||
require.FailNow(t, fmt.Sprintf("No results returned from the counterPath: %v", len(hostCounters.counters))) | ||
} else if len(hostCounters.counters) > 1 { | ||
require.FailNow(t, "too many results returned from the counterPath: %v", len(hostCounters.counters)) | ||
require.FailNow(t, fmt.Sprintf("Too many results returned from the counterPath: %v", len(hostCounters.counters))) |
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.
require.FailNowf
! Anyway, this will prevent any deferred function to run IIRC. Shouldn't we simply test with
require.Len(t, hostCounters.counters, 1)
? Same for the other tests below.
@@ -214,7 +214,7 @@ func TestWriteTagsAsResourceLabels(t *testing.T) { | |||
case "test_cpu_value/unknown": | |||
require.Equal(t, "cpu", ts.Resource.Labels["job_name"]) | |||
default: | |||
require.False(t, true, "Unknown metric type") | |||
require.Fail(t, fmt.Sprintf("Unknown metric type: %v", ts.Metric.Type)) |
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.
require.Failf
. Same for all other instances!
testutil/accumulator.go
Outdated
@@ -399,8 +399,7 @@ func (a *Accumulator) AssertContainsTaggedFields( | |||
t.Log("measurement", p.Measurement, "tags", p.Tags, "fields", p.Fields) | |||
} | |||
} | |||
msg := fmt.Sprintf("unknown measurement %q with tags %v", measurement, tags) | |||
require.Fail(t, msg) | |||
require.Fail(t, fmt.Sprintf("Unknown measurement %q with tags %v", measurement, tags)) |
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.
require.Fail(t, fmt.Sprintf("Unknown measurement %q with tags %v", measurement, tags)) | |
require.Failf(t, "Unknown measurement %q with tags %v", measurement, tags) |
testutil/accumulator.go
Outdated
"found measurement %s with tagged fields (tags %v) which should not be there", | ||
measurement, tags) | ||
require.Fail(t, msg) | ||
require.Fail(t, fmt.Sprintf("Found measurement %s with tagged fields (tags %v) which should not be there", measurement, tags)) |
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.
Please use require.Failf
wherever possible!
Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip. 📦 Click here to get additional PR build artifactsArtifact URLs |
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.
Awesome @zak-pawel! Thanks a lot!
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.
@zak-pawel Great work on this PR!
(cherry picked from commit 080e9a1)
Summary
More info about major version update: https://golangci-lint.run/product/changelog/#201
In this PR:
.golangci-lint
config fromv1
tov2
using:golangci-lint migrate
: https://golangci-lint.run/product/migration-guide/.staticcheck
,stylecheck
, andgosimple
have been merged into a single linter (staticcheck
). A lot of new issues were detected bystaticcheck
, but I'm not addressing them in this PR. Instead, I disabled the newly appearing checks - we can consider handling them in the future.Checklist