Skip to content

refactor: add missing error checks #7079

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

Merged
merged 1 commit into from
May 11, 2020
Merged

Conversation

ankitm123
Copy link
Member

Signed-off-by: ankitm123 [email protected]

Submitter checklist

  • Change is code complete and matches issue description.
  • Change is covered by existing or new tests.

Which issue this PR fixex

fixes #6851

@jenkins-x-bot
Copy link
Contributor

Hi @ankitm123. Thanks for your PR.

I'm waiting for a jenkins-x 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.

@hferentschik hferentschik changed the title [WIP] refactor: add missing error checks [wip] refactor: add missing error checks Apr 20, 2020
@hferentschik
Copy link

/ok-to-test

@ankitm123
Copy link
Member Author

/test lint

@ankitm123
Copy link
Member Author

So after rebasing, the lint failed again. So, I decided to split the linting into two files - linter.sh and linter-extra.sh, keeping the increased limits for both of those linting jobs.

@ankitm123
Copy link
Member Author

/test lint

Copy link

@hferentschik hferentschik left a comment

Choose a reason for hiding this comment

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

Looking good. Not so sure between the separation between lint and lint-extra. Where is the differentiation and how would we evolve things? Were would one add a new check and why? Can you explain your motivation?

Makefile Outdated
@@ -213,6 +213,7 @@ importfmt: get-fmt-deps
lint: ## Lint the code
./hack/gofmt.sh
./hack/linter.sh
./hack/linter-extra.sh

Choose a reason for hiding this comment

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

Why the separation? What do you try to achieve?

${DIR}/install_golint.sh -b $GOPATH/bin v1.20.0
fi

export GO111MODULE=on

Choose a reason for hiding this comment

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

Personally, I find it hard to see what the difference between lint and lint-extra is. I fear this might confuse others as well. What do we gain?

AFAICT, the bulk of the scripts are identical. So if we really want to split into multiple lint steps in Makefile and jenkins-x-lint.yaml, then I think it should be a single linter script and you pass in by argument which checks to run.

If this is just about splitting into more tasks and contexts, one thing I want to do for a long time it to break out a codegen context (`jenkins-x-codegen.yaml) and so the code generation checks separately. That's technically really not linting and it has confused people before. I'd rather do that than splitting lint and lint-extra (unless there is something I am missing here)

Copy link
Member Author

Choose a reason for hiding this comment

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

lint -> all the old linters, lint-extra -> new linters (ununsed and errcheck). It's a bit difficult for me to know where the script really fails. I tried various combinations, and this is the one which succeeded. I think it might make sense to coordinate over slack, if that's an option. I can try making the changes, and if you can get me the logs, that would help us debug it 🥇 wdyt? Let me try to separate the code gen from linting, and see what happens.

if err != nil {
return errors.Wrapf(err, "checking if file %s exists", path)
}
if exists {

Choose a reason for hiding this comment

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

👍 sweet

@@ -123,7 +123,10 @@ func (o *GetPipelineOptions) Run() error {
if err != nil {
return err
}
o.dump(jenkins, job.Name, &table)
err = o.dump(jenkins, job.Name, &table)

Choose a reason for hiding this comment

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

👍

@@ -90,7 +92,10 @@ func (e ElasticsearchProvider) SendRelease(r *v1.Release) error {
r.Namespace: r.CreationTimestamp.String(),
},
}
e.SendIssue(&esissue)
err = e.SendIssue(&esissue)
if err != nil {

Choose a reason for hiding this comment

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

👍

@ankitm123
Copy link
Member Author

ankitm123 commented May 11, 2020

@hferentschik combining all the linters into one lint file, made it fail again. Can we increase the memory further. There is also the option to use a lower value of GOGC, this will reduce the memory usage, but at the expense of making the tests run longer. https://github.com/golangci/golangci-lint#memory-usage-of-golangci-lint
The jx code base is much bigger than the golangci-lint repo, so it makes sense why it breaks. Also in the future, we should add more linters (staticcheck, go cyclo), which will make it impossible to lint the code base imo. Wdyt? fyi, istio uses abt 31GB to lint it's codebase 😄

@ankitm123
Copy link
Member Author

ankitm123 commented May 11, 2020

So the lint passed after I set GOGC=10 💯 . Not sure, how to add the new code-gen to the list of existing checks ...

Copy link

@hferentschik hferentschik left a comment

Choose a reason for hiding this comment

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

Looking good, let me enable jenkins-x-codegen context so that we can see this context run. Once it is configured we can see it works and merge. Then we will make it a required context.

@@ -0,0 +1,32 @@
buildPack: none

Choose a reason for hiding this comment

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

👍

Choose a reason for hiding this comment

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

we will need to enable the new context in the configuration for the repo.

- name: generate
image: golang:1.12.10
command: ./hack/generate.sh
dir: /workspace/go/src/github.com/jenkins-x/jx

Choose a reason for hiding this comment

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

nitpick, missing newline

@hferentschik
Copy link

@ankitm123 - fyi https://github.com/jenkins-x/environment-tekton-weasel-dev/pull/581. Once that's merging the new context should appear and we can rebuild the whole PR. If all looks good we can merge and then we can make it a required context.

@hferentschik
Copy link

/test codegen

@hferentschik
Copy link

@ankitm123 :

Showing logs for build jenkins-x-jx-pr-7079-codegen-gvrfd-189 stage ci and container step-generate
/bin/sh: 1: cd: can't cd to /workspace/go/src/github.com/jenkins-x/**
Pipeline failed on stage 'ci' : container 'step-generate'. The execution of the pipeline has stopped.

I think we need the copy parts from the lint status check as well to move the sources to the "right" location. At least while we are still on Go 1.12.

@ankitm123
Copy link
Member Author

ankitm123 commented May 11, 2020

@hferentschik great, the codegen bit works now, gonna remove that copy part from the lint (it's not needed any more imo).

@abayer
Copy link
Contributor

abayer commented May 11, 2020

/retest

cpu: 3
memory: 6Gi
steps:
- name: mk-jx-project-dir

Choose a reason for hiding this comment

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

:+1

@hferentschik
Copy link

/lgtm

@jenkins-x-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hferentschik

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

@jenkins-x-bot jenkins-x-bot merged commit 22ce213 into jenkins-x:master May 11, 2020
@cagiti
Copy link
Contributor

cagiti commented May 14, 2020

This is a great change, but I think it would be useful to log an error for missing error checks in one PR before returning the error, because it alters behaviour of the codebase (albeit incorrect). Then a subsequent PR which returns the error would be required (when the impact is understood), and arguably could be a case for a minor version increment.

@ankitm123
Copy link
Member Author

This is a great change, but I think it would be useful to log an error for missing error checks in one PR before returning the error, because it alters behaviour of the codebase (albeit incorrect_). Then a subsequent PR which returns the error would be required (when the impact is understood), and arguably could be a case for a minor version increment.

You are right. Honestly, I thought that this PR might lead to some cases, where the downstream code relies on no errors being returned. There are about 90 places in the codebase where I have skipped errchecks (using nolint). Not catching the error can lead to unintended results though, for instance we still dont handle errors for any of the defer functions and I am not sure what kind of bugs they have introduced (for instance we dont know if those files are being closed properly). Are you seeing any places where handling the errors have led to some issues? Would be nice to re-evaluate the logic there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Run errcheck as part of the checks when merging a PR
6 participants