8000 fix errorlint linter by mmorel-35 · Pull Request #50158 · moby/moby · GitHub
[go: up one dir, main page]

Skip to content

Conversation

mmorel-35
Copy link
Contributor
@mmorel-35 mmorel-35 commented Jun 8, 2025
edited
Loading

- What I did

Enables errorlint linter with comparison rule and fixes issues. The errorf, errorf-multi and assert rules are disabled because it requires a number of changes that deserves a dedicated PR

- How I did it

- How to verify it

- Human readable description for the release notes

- A picture of a cute animal (not mandatory but encouraged)

@mmorel-35 mmorel-35 force-pushed the errorlint branch 6 times, most recently from 37680b9 to 266e00f Compare June 9, 2025 05:25
@mmorel-35 mmorel-35 marked this pull request as ready for review June 9, 2025 06:00
@vvoland vvoland added area/testing kind/refactor PR's that refactor, or clean-up code labels Jun 9, 2025
@vvoland vvoland added this to the 28.2.3 milestone Jun 9, 2025
Copy link
Contributor
@vvoland vvoland left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@thaJeztah
Copy link
Member

CI looks happy, so it's probably fine to bring this in; my only concern is that changing %v -> %w means that some underlying errors are now propagated. I wonder if there's cases where errors were on purpose "masked" (i.e., deliberately mask a NotFound error to prevent it being handled further up the stack).

@robmry @vvoland any thoughts / concerns?

(such cases of course should've been caught in CI, but not sure if there's always cases to check for "unknown" situations)

@robmry
Copy link
Contributor
robmry commented Jun 10, 2025

I don't know of anywhere the underlying error is deliberately masked ... but that just means I don't know, I wouldn't bet on CI catching that sort of thing. We don't know of any issues caused by the masking. There's also a lot of change, too much to review in any detail.

So, yes - the %v -> %w change seems risky, and the benefits aren't clear enough (to me) to make the risk worthwhile

The errors.Is change seems good though.

@thaJeztah
Copy link
Member

To reduce risk (for now), could you move the second commit (for errors.Is) to a separate PR (or vice-versa) @mmorel-35 ? Then we can get those changes in already (hopefully reducing some rebase-hell on your side).

@mmorel-35
Copy link
Contributor Author

@thaJeztah ,
I just kept the errors.Is changes

# Check for plain type assertions and type switches.
asserts: false
Copy link
Member

Choose a reason for hiding this comment

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

This one looks enabled by default, and I think this PR should fix these, or are there more remaining that are not yet fixed? If all of them are fixed, we can remove these lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As I said initially in the description of the PR, I did not treated asserts because this needs a lot of change.
I believe it is better to have a dedicated one for that purpose.

Copy link
Member

Choose a reason for hiding this comment

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

oh! I mis-interpreted assert as the ones that were fixed in this PR (use errors.Is / errors.As) 🙈

@mmorel-35 mmorel-35 force-pushed the errorlint branch 2 times, most recently from f54f7d2 to ac8ee2d Compare June 10, 2025 14:36
Copy link
Contributor
@robmry robmry left a comment

Choose a reason for hiding this comment

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

LGTM - thank you

@mmorel-35 mmorel-35 force-pushed the errorlint branch 4 times, most recently from 313c4d9 to ed30ee4 Compare June 10, 2025 18:58
@vvoland vvoland modified the milestones: 28.2.3, 28.3.0 Jun 11, 2025
@thaJeztah
Copy link
Member

Probably unrelated, but in case it isn't;

=== Failed
=== FAIL: github.com/docker/docker/integration-cli TestDockerAPISuite/TestContainersAPICreateMountsCreate/0_config:_{volume__c:\foo_false__<nil>_<nil>_<nil>_<nil>_<nil>} (12.45s)
    docker_api_containers_test.go:1951: timeout hit after 10s: container 1ce3b5503af061a39bf6d2c76d2f10f57de57ca7befb27eaae09f46de993b3ad is running, waiting for exit

=== FAIL: github.com/docker/docker/integration-cli TestDockerAPISuite/TestContainersAPICreateMountsCreate (33.20s)

=== FAIL: github.com/docker/docker/integration-cli TestDockerAPISuite (456.54s)

Copy link
Member
@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

Thanks! LGTM after the //nolint comments are addressed to prevent the extra code-churn

Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>

Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
Copy link
Member
@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/testing kind/refactor PR's that refactor, or clean-up code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0