fix(lint): explicitly configures ireturn exceptions #1085
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of using `//nolint:ireturn` the linter allows a use of `generic` return types (on top of the listed defaults which now have been explicitly set). This approach also eliminates a re-occuring issue where `nolintlint` reports aforementioned directive as not used by defined linter. Related issue: golangci/golangci-lint#3228 On top of that we have `--fix` flag enabled for golangci-lint runner. This results in removal of these comments as `nolintlint` tries to autofix. As a consequence the subsequent run of `make lint` yields errors for previously disabled linters and the cycle continues :) > [!IMPORTANT] > This behaviour has also been observed for other linters. As part of this the declarations of kustomize plugin constructor funcs has been reworkted to return struct pointers instead. The reason for this is that in our feature branch we are relying on kustomize plugins and want to iterate over a slice of resmap.Transfomers but in the current form these functions cannot be used due to the fact that structs returned have pointer receivers. From the current functionality standpoint (on incubation branch) this change is harmless.
ykaliuta
approved these changes
Jun 26, 2024
zdtsw
approved these changes
Jun 26, 2024
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ykaliuta, zdtsw 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 |
openshift-merge-bot
bot
merged commit 613d552
into
opendatahub-io:incubation
8 checks passed
VaishnaviHire
pushed a commit
to VaishnaviHire/opendatahub-operator
that referenced
this pull request
Jul 24, 2024
) Instead of using `//nolint:ireturn` the linter allows a use of `generic` return types (on top of the listed defaults which now have been explicitly set). This approach also eliminates a re-occuring issue where `nolintlint` reports aforementioned directive as not used by defined linter. Related issue: golangci/golangci-lint#3228 On top of that we have `--fix` flag enabled for golangci-lint runner. This results in removal of these comments as `nolintlint` tries to autofix. As a consequence the subsequent run of `make lint` yields errors for previously disabled linters and the cycle continues :) > [!IMPORTANT] > This behaviour has also been observed for other linters. As part of this the declarations of kustomize plugin constructor funcs has been reworkted to return struct pointers instead. The reason for this is that in our feature branch we are relying on kustomize plugins and want to iterate over a slice of resmap.Transfomers but in the current form these functions cannot be used due to the fact that structs returned have pointer receivers. From the current functionality standpoint (on incubation branch) this change is harmless. (cherry picked from commit 613d552)
VaishnaviHire
pushed a commit
to VaishnaviHire/opendatahub-operator
that referenced
this pull request
Jul 24, 2024
) Instead of using `//nolint:ireturn` the linter allows a use of `generic` return types (on top of the listed defaults which now have been explicitly set). This approach also eliminates a re-occuring issue where `nolintlint` reports aforementioned directive as not used by defined linter. Related issue: golangci/golangci-lint#3228 On top of that we have `--fix` flag enabled for golangci-lint runner. This results in removal of these comments as `nolintlint` tries to autofix. As a consequence the subsequent run of `make lint` yields errors for previously disabled linters and the cycle continues :) > [!IMPORTANT] > This behaviour has also been observed for other linters. As part of this the declarations of kustomize plugin constructor funcs has been reworkted to return struct pointers instead. The reason for this is that in our feature branch we are relying on kustomize plugins and want to iterate over a slice of resmap.Transfomers but in the current form these functions cannot be used due to the fact that structs returned have pointer receivers. From the current functionality standpoint (on incubation branch) this change is harmless. (cherry picked from commit 613d552)
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Instead of using
//nolint:ireturnthe linter allows the use ofgenericreturn types through the global config (on top of the listed defaults which now have been explicitly set).This approach also eliminates a recurring issue where
nolintlintreports the directive above as not used by the defined linter.Related issue: golangci/golangci-lint#3228
On top of that, we have
--fixflag enabled forgolangci-lintrunner. This results in the removal of these comments asnolintlinttries to auto fix.As a consequence the subsequent run of
make lintyields errors for previously disabled linters and the cycle continues :)Important
This behaviour has also been observed for other linters.
As part of this work, the declarations of kustomize plugin constructor funcs has been reworked to return struct pointers instead. The reason for this is that in our feature branch, we rely on kustomize plugins and want to iterate over a slice of
resmap.Transfomersbut these functions cannot be used in the current form because structs returned have pointer receivers. From the current functionality standpoint (on the incubation branch) this change is harmless.How Has This Been Tested?
makeScreenshot or short clip
Merge criteria
Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).