Add linter to the building pipeline

[rdner]

What does this PR do?

• Added the mage targets
• Added the linting configuration
• Added the steps to Jenkinsfile

WARNING! After merging this PR developers will be forced into fixing all linter issues in the entire files they change.

Why is it important?

The linter proved itself useful in the elastic-agent-libs repository and uncovered some bugs. This will allow us to catch certain problems (e.g. not checked error) before our customers report them.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
  - [ ] I have made corresponding changes to the documentation
  - [ ] I have made corresponding change to the default configuration files
  - [ ] I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

How to test this PR locally

To run the linter on the entire repository (can take minutes to complete and would most likely emit a lot issues

mage lint

Or run against files touched by the difference of the current branch and main (lint last change).

mage llc

Related issues

• Closes Add linting based on the elastic-agent-libs for Beats #30545

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[mergify]

This pull request does not have a backport label. Could you fix it @rdner? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-03-22T08:41:12.615+0000

• Duration: 106 min 46 sec

Test stats 🧪

Test	Results
Failed	0
Passed	22523
Skipped	1940
Total	24463

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

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

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b add-linter upstream/add-linter
git merge upstream/main
git push upstream add-linter

[cmacknz]

WARNING! After merging this PR developers will be forced into fixing all linter issues in the entire files they change.

We should communicate the impact of this change to everyone who works on beats, at least the beats-contrib mailing list. Maybe link the PR to show what linters will be enabled.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b add-linter upstream/add-linter
git merge upstream/main
git push upstream add-linter

[andrewkroh]

For stylecheck (or some other linter) could we check that godoc follows the https://staticcheck.io/docs/checks/#ST1020. Like if you are going to put effort into writing docs for your exported function then follow the Go conventions 😄. FWIW we have that check in go-libaudit (had to disable one of the default excludes).

[rdner]

I actually thought it was the default behaviour, I used to see this errors before in one of my previous projects. I tested locally and even with checks: ["all"] for staticcheck and stylecheck it didn't return any errors for missing or malformed go doc strings. I'll investigate further.

[andrewkroh]

It's probably one of the default rules for excluding issues listed in https://golangci-lint.run/usage/configuration#command-line-options. Like maybe EXC0014.

Adding something like this can workaround it:

issues:
  include:
   # If you're going to write a comment follow the conventions.
   # https://go.dev/doc/effective_go#commentary.
   # comment on exported (.+) should be of the form "(.+)..."
   - EXC0014

[rdner]

I'll add it later as a separate PR, since this is already stable and approved.

[matschaffer]

I landed here after hitting lint errors regarding github.com/pkg/errors - looks like it's sufficient to replace calls to

errors.Wrap(err, "error message"))

with

fmt.Errorf("error message: %w", err))

Thought I'd mention it here for confirmation and incase it helps others resolve the replacement.