Skip to content
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

fix: enable formatter rule from testifylint #18741

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ghouscht
Copy link
Contributor

This PR enables the formatter testifylint rule as part of #18719

Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.

@k8s-ci-robot
Copy link

Hi @ghouscht. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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-sigs/prow repository.

@codecov-commenter
Copy link

codecov-commenter commented Oct 15, 2024

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 70.37037% with 8 lines in your changes missing coverage. Please review.

Project coverage is 68.82%. Comparing base (fa89ee0) to head (10f76ac).
Report is 8 commits behind head on main.

Current head 10f76ac differs from pull request most recent head be02cdb

Please upload reports for the commit be02cdb to get more accurate results.

Files with missing lines Patch % Lines
etcdctl/ctlv3/command/ep_command.go 0.00% 6 Missing ⚠️
client/v3/config.go 85.71% 1 Missing and 1 partial ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
Files with missing lines Coverage Δ
server/storage/mvcc/testutil/hash.go 83.78% <100.00%> (ø)
client/v3/config.go 84.90% <85.71%> (+0.29%) ⬆️
etcdctl/ctlv3/command/ep_command.go 0.00% <0.00%> (ø)

... and 23 files with indirect coverage changes

@@            Coverage Diff             @@
##             main   #18741      +/-   ##
==========================================
+ Coverage   68.73%   68.82%   +0.08%     
==========================================
  Files         420      420              
  Lines       35488    35481       -7     
==========================================
+ Hits        24392    24419      +27     
+ Misses       9661     9635      -26     
+ Partials     1435     1427       -8     

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fa89ee0...be02cdb. Read the comment docs.

@@ -40,12 +40,12 @@ func AssertNotNil(t *testing.T, v any) {
// Deprecated: use github.com/stretchr/testify/assert.True instead.
func AssertTrue(t *testing.T, v bool, msg ...string) {
t.Helper()
assert.True(t, v, msg)
assert.True(t, v, msg) //nolint:testifylint
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both the AssertTrue and AssertFalse functions are part of the public API of the testutils pkg. It looks like they are no longer used within the etcd codebase but they could be used outside of the etcd codebase. I thought it is best to keep them as they are, thus the nolint directive. Let me know if you think that is ok.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Until this code is removed, it's better to keep it as is . I agree to disable the linter here

@ghouscht
Copy link
Contributor Author

FYI: @mmorel-35 here is the second PR for the formatterrule. From my point of view it is ready but I marked it as draft to keep the number of open and ready testifylint PRs small.

@ghouscht ghouscht mentioned this pull request Oct 15, 2024
13 tasks
@mmorel-35
Copy link
Contributor

There are many places where the expected or unexpected error is is printed with : %v", err

I'm wondering if it's not redondant with the behavior of testify which will print it

@ghouscht
Copy link
Contributor Author

There are many places where the expected or unexpected error is is printed with : %v", err

I'm wondering if it's not redondant with the behavior of testify which will print it

Yes, that is true. I can clean them up if you and the maintainers agree on that.

@mmorel-35
Copy link
Contributor

Yes, that is true. I can clean them up if you and the maintainers agree on that.

I feel like it's the best opportunity to do that as most of them are probably modified in this PR.

Let's see what the maintainers think.


leaderIndex := epc.WaitLeader(t)
_, err = epc.Procs[leaderIndex].Logs().ExpectWithContext(ctx, expect.ExpectedResponse{Value: "finished compaction hash check"})
require.NoError(t, err, "can't get log indicating finished compaction hash check")
require.NoErrorf(t, err, "can't get log indicating finished compaction hash check")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: there is no variable-length variable in this case, shouldn't require.NoError be better than require.NoErrorf?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note this is a generic question.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same question and the author of linter directed me to the rule's documentation:

https://github.com/Antonboom/testifylint?tab=readme-ov-file#formatter

And the historical note associated:

https://github.com/Antonboom/testifylint?tab=readme-ov-file#historical-reference

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should always use *f functions when require-f-funcs: true no matter there is variable-length variables or not?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to be the recommended way to do indeed

- go-require
- require-error
enable-all: true
formatter:
require-f-funcs: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this option mean? Could you add a comment to clarify?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://golangci-lint.run/usage/linters/#testifylint states:

To require f-assertions if format string is used.

I'll add a comment 👍🏻

@ahrtr
Copy link
Member

ahrtr commented Oct 16, 2024

There are many places where the expected or unexpected error is is printed with : %v", err

I'm wondering if it's not redondant with the behavior of testify which will print it

Yes, testify already prints the error, so we don't need to print it again. But not a big deal.

@ghouscht ghouscht force-pushed the testifylint-formatter branch 2 times, most recently from 4babfc2 to 2d144f0 Compare October 16, 2024 12:18
@k8s-ci-robot k8s-ci-robot added the github_actions Pull requests that update GitHub Actions code label Oct 16, 2024
Signed-off-by: Thomas Gosteli <thomas.gosteli@protonmail.ch>
@ghouscht
Copy link
Contributor Author

There are many places where the expected or unexpected error is is printed with : %v", err
I'm wondering if it's not redondant with the behavior of testify which will print it

Yes, testify already prints the error, so we don't need to print it again. But not a big deal.

👍🏻 I cleaned up the messages and removed redundant information.

@k8s-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ghouscht, mmorel-35
Once this PR has been reviewed and has the lgtm label, please assign wenjiaswe for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mmorel-35
Copy link
Contributor

@ghouscht ,
Feel free to undraft when you you are ready

@ghouscht ghouscht marked this pull request as ready for review October 16, 2024 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants