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

🌱 lint: fix the JSON encoding check error via errchkjson linter #2273

Merged

Conversation

MrDXY
Copy link
Contributor

@MrDXY MrDXY commented Aug 23, 2023

What this PR does / why we need it:

  1. Fix the checked error by errchkjson linter. (remove the safe returns of errors from json.Marshal)
  2. Enable errchkjson check in .golangci.yml configuration file.
  3. Enable linters-settings.errchkjson.check-error-free-encoding. With it set to true, errchkjson does not report about the errors from json encoding functions that are safe to be ignored, because they are not possible to happen.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #2058

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Aug 23, 2023
@k8s-ci-robot
Copy link
Contributor

Hi @MrDXY. 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 /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/test-infra repository.

@k8s-ci-robot k8s-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Aug 23, 2023
.golangci.yml Outdated
Comment on lines 57 to 58
errchkjson:
check-error-free-encoding: true
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
errchkjson:
check-error-free-encoding: true

We should not set this to be equal to CAPI and resolve the findings instead by handling the error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I can make the necessary adjustments here, and it totally makes sense that we prefer to keep consistent with CAPI.

To discuss it further:
This check-error-free-encoding parameter here, is just to indicate the errchkjson to ignore the errors that will never happen.

Especially in some cases:

sshKey, _ := json.Marshal(env.VSphereSSHAuthorizedKeysVar)
controlPlaneIP, _ := json.Marshal(env.ControlPlaneEndpointVar)
secretName, _ := json.Marshal(env.ClusterNameVar)
kubeVipPod, _ := json.Marshal(kubeVIPPodYaml())

the input of the json.Marsha() is just a string, which will never cause the function to fail, IIRC. To handle such a situation, is it a good idea to propagate errors to the higher-level calling function? Or do you recall any recommended approaches that I could follow?

Copy link
Member

Choose a reason for hiding this comment

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

I did see that the required changes would only be in the flavorgen tool. So just bubbling them up should be fine.

Copy link
Contributor Author

@MrDXY MrDXY Aug 23, 2023

Choose a reason for hiding this comment

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

Sorry to ask, just want to make sure, bubbing them up means bubbling the error up to the higher-level function, right?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. No worries, just ask all good :)

Copy link
Member

Choose a reason for hiding this comment

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

Alright. So keeping it as is is fine :)

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with keeping it as it's the consensus - but I don't really like relying on external linters like this for something this fundamental, at the cost of saving a few lines of if err == nil'{}

Copy link
Member

Choose a reason for hiding this comment

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

Good point on relying on an external linter. Basically if they have a bug in their logic we inherit that in CAPI as well

Copy link
Member

Choose a reason for hiding this comment

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

Alright, changing my opinion again. Now I'm in favor of dropping the check-error-free-encoding config

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@chrischdi It's totally fine! Still, welcome any advice or suggestions you may have.
@sbueringer Got it!

Copy link
Contributor

@killianmuldoon killianmuldoon left a comment

Choose a reason for hiding this comment

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

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Aug 23, 2023
@sbueringer
Copy link
Member

sbueringer commented Aug 23, 2023

/lgtm

/assign @killianmuldoon @chrischdi

Would be nice, if someone has time, to follow-up to do the same in core CAPI. I think it's really helpful if we get rid of error branches that can never happen.

See: #2273 (comment)

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 23, 2023
@sbueringer
Copy link
Member

/lgtm cancel

@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 23, 2023
@MrDXY MrDXY force-pushed the pr-golangci-sync-errchkjson branch from ec6c555 to b23ef2d Compare August 24, 2023 03:45
@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Aug 24, 2023
@MrDXY MrDXY force-pushed the pr-golangci-sync-errchkjson branch from b23ef2d to 27c14a9 Compare August 24, 2023 03:48
@MrDXY MrDXY force-pushed the pr-golangci-sync-errchkjson branch from 27c14a9 to 2e2f203 Compare August 24, 2023 04:20
Copy link
Contributor

@killianmuldoon killianmuldoon 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 for this!

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 24, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 4fc5dadd58eb94498c98ead0031f94e130941a92

Copy link
Member

@chrischdi chrischdi left a comment

Choose a reason for hiding this comment

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

/lgtm
/approve

Thanks!

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chrischdi

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 24, 2023
@k8s-ci-robot k8s-ci-robot merged commit 2ddce8c into kubernetes-sigs:main Aug 24, 2023
7 checks passed
@k8s-ci-robot k8s-ci-robot added this to the v1.9 milestone Aug 24, 2023
cluster := newClusterClassCluster()
cluster, err := newClusterTopologyCluster()
if err != nil {
return nil
Copy link
Member

@sbueringer sbueringer Aug 24, 2023

Choose a reason for hiding this comment

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

I think we should return the error here

I think if we choose to handle the error we should propagate (bubble) it up the entire call hierarchy

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have considered this previously, and I choose to return nil for the following reason:

  • the function ClusterTopologyTemplateKubeVIP() []runtime.Object does not have a return value for the error, so I'll need to modify the API structure to fit it in. While this method is public, I'm not sure if this will cause some trouble for other customers who might be using it to generate their templates.

  • Since we know that this method will not actually produce an error (the json-encoding error is safe to ignore), it may be okay not to expose it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But it's also OK. If we consider it inappropriate to ignore the error. I can make some adjustments to the function.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, totally missed that 🤦

Copy link
Member

@sbueringer sbueringer Aug 24, 2023

Choose a reason for hiding this comment

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

Let's make the adjustment to the func to add the error return parameter. I think for this sort of code it should be okay if we evolve it a bit over time (not sure if anyone apart from us is using this util / it's exported functions)

It just feels consistent to handle the error if we choose to handle it and not drop it one level up the call hierarchy :)

Copy link
Member

Choose a reason for hiding this comment

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

Ah looks like Christian opened a PR already

Copy link
Member

Choose a reason for hiding this comment

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

I created #2274 so we don't forget to fix that.

In this case its way better to bubble up even if we currently know the current code does not produce an error.

There should either only be the two extremes:

  • bubbling up
  • or ignore the error where we get it, not somewhere in-between

Copy link
Member

Choose a reason for hiding this comment

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

Yup, all good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants