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

Create linter configuration and address found issues #10

Merged
merged 13 commits into from
Feb 17, 2022

Conversation

rdner
Copy link
Member

@rdner rdner commented Feb 16, 2022

This PR is to propose the linting configuration that we are going to re-use for new repositories.

Also, all the currently found linting issues are fixed in this PR which can give an idea what kind of common issues we have now in our code and which the linter finds.

Closes elastic/beats#30150

@rdner rdner added the Team:Elastic-Agent-Data-Plane Label for the Agent Data Plane team label Feb 16, 2022
@rdner rdner self-assigned this Feb 16, 2022
@elasticmachine
Copy link
Collaborator

elasticmachine commented Feb 16, 2022

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2022-02-17T10:16:01.240+0000

  • Duration: 15 min 42 sec

Test stats 🧪

Test Results
Failed 0
Passed 124
Skipped 0
Total 124

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

.golangci.yml Outdated

prealloc:
# XXX: we don't recommend using this linter before doing performance profiling.
# For most programs usage of prealloc will be a premature optimization.
Copy link

Choose a reason for hiding this comment

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

@rdner Looking at the comment we might want to remove it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Every comment was just copied from the official doc. And it makes sense to me. By default, we should pre-allocate but it does not mean that it's required.

Copy link
Member Author

Choose a reason for hiding this comment

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

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 not a huge fan of this one either, I'm not a huge fan of premature optimisations. I'm just wondering if it can get noisy.

Copy link
Member Author

Choose a reason for hiding this comment

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

I believe if it's known one should always set capacity when allocating, for example:

b := map[string]interface{}{}
a := make([]string, 0, len(b)) // vs `var a []string`

for key := range b {
  a = append(a, key)
}

Copy link
Member Author

@rdner rdner Feb 16, 2022

Choose a reason for hiding this comment

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

I removed the comment that it would not scare anyone. I'd like to keep the linter though unless everyone are oppose it.

Copy link
Member

Choose a reason for hiding this comment

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

I don't mind this, it's not an optimization that makes the code harder to read. If anything it makes the allocation more obvious.

I have seen preallocating like this make a big performance difference in frequently used code that creates small slices/arrays. The underlying array doubles when there's not enough capacity, which happens more frequently if the slice was empty and stays small (per "Growing Slices" in https://go.dev/blog/slices-intro)

# Enable to require nolint directives to mention the specific linter being suppressed. Default is false.
require-specific: true

staticcheck:
Copy link

@ph ph Feb 16, 2022

Choose a reason for hiding this comment

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

NIT: It would be nice to have the 1.17 to be populated by the .go-version file, could be done with the mage task.

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, that would mean we make a template configuration that we build on CI right before we run the linter.

These versions are configurations for built-in linters, so every built-in linter (plugin) is free to choose how they configure themselves and they don't seem to support .go-version.

Copy link
Contributor

Choose a reason for hiding this comment

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

In the long run it would be nice to have it reading from .go-version so we don't need to remember to update this configuration file as we change our Go version.

Because we're most likely running it with mage, I see no issue on adding this automation.

Copy link

Choose a reason for hiding this comment

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

@rdner This shouldn't be a lot of effort, we have already code generation. There is a make update task that generates the configuration files from templates and other generated files. That make update comment is run on every build, if git status detects new files or modified files it will fail the build.

So the workflow would be like this.

But on the other side we will have 1.17 for some time and 1.18 for quite some time, I just hate having multiple files to updates we still have too much and removing the human in the operation is always a good thing and having multiple go repository that just work the same would save us time.

Copy link
Member Author

@rdner rdner Feb 17, 2022

Choose a reason for hiding this comment

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

@ph This PR already has a ton of comments, I'm not going to implement it here but I can take it as my next step.

Copy link

@ph ph left a comment

Choose a reason for hiding this comment

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

Change looks to me, the number of linter feels a bit overwhelming, adding a comment to remove the prealloc since we haven't done any performance analysis, yet and we with the architecture change it might be premature to worry about it. If possible we should remove the 1.17 magic number from that files, we can populate it from the .go-version file.

To reduce the noise and make the run faster, it would be nice in ci if the check was only run on the added or modified files. This would allow us to enforce it from day 1, and incrementally improve the code as we go.

So far, I would be +1 to share the same across all of our repositories.

Copy link
Contributor

@belimawr belimawr left a comment

Choose a reason for hiding this comment

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

Great job @rdner !!

One little detail, once the PR is finalised, what about sorting the liners alphabetically? I feel it makes reading easier.

@cmacknz
Copy link
Member

cmacknz commented Feb 16, 2022

Thanks for proposing this @rdner. There is a lot to deal with to get this enabled it seems.

sh(label: 'lint', script: '''
go mod tidy && git diff --exit-code
gofmt -l . | read && echo "Code differs from gofmt's style. Run 'gofmt -w .'" 1>&2 && exit 1 || true
''')
Copy link
Member Author

Choose a reason for hiding this comment

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

  • go mod tidy has been moved to the magefile
  • gofmt is now included into the new linter

sh(label: 'Mage check', script: 'mage check')
sh(label: 'Go vet', script: 'go vet ./...')
Copy link
Member Author

@rdner rdner Feb 17, 2022

Choose a reason for hiding this comment

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

Is now included into the new linter.

@@ -380,7 +384,12 @@ func (r *Rotator) closeFile() error {
}
err := r.file.Close()
r.file = nil
return errors.Wrap(err, "failed to close active file")
Copy link
Member Author

Choose a reason for hiding this comment

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

Wrap returns nil if the err == nil, fmt.Errorf does not, so had to adjust.

@rdner
Copy link
Member Author

rdner commented Feb 17, 2022

Since this PR is already quite big, I'm going to create a follow-up PR where I will add support for:

  • .go-version file and templating the linting configuration
  • mage LintLastCommit which will lint only Go-files affected by the last commit (which will become the default on our CI).

@rdner rdner requested review from ph, cmacknz, kvch and belimawr February 17, 2022 10:31
Copy link

@faec faec left a comment

Choose a reason for hiding this comment

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

🎉

@rdner rdner merged commit cb28916 into elastic:main Feb 17, 2022
@rdner rdner deleted the add-linter branch February 17, 2022 16:05
Copy link
Contributor

@belimawr belimawr left a comment

Choose a reason for hiding this comment

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

I know it has been merged, but I'm still submitting it so I don't lose all I've written :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Elastic-Agent-Data-Plane Label for the Agent Data Plane team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create a base linter configuration
7 participants