Set up workflow for golangci

[mmorel-35]

This PR doesn't fix the identified problem raised by the analysis

[gmlewis]

What prompted you to write this PR?

[mmorel-35]

Hi! I saw it defined in https://github.com/google/go-querystring, I thought the project might be interested

[gmlewis]

@willnorris - I defer to your judgment on this one and #2019.

[obalunenko]

suggest to add ercheck and govet to the list
https://golangci-lint.run/usage/linters/

[mmorel-35]

Those two are active by default, see https://golangci-lint.run/usage/linters/#enabled-by-default-linters. I haven't deactivated them. It would require disable-all to be true under the linters item in this case
https://golangci-lint.run/usage/configuration/#config-file

[codecov]

Codecov Report

Merging #2020 (4bcc57b) into master (a12f9cd) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #2020   +/-   ##
=======================================
  Coverage   97.86%   97.87%           
=======================================
  Files         107      107           
  Lines        6901     6907    +6     
=======================================
+ Hits         6754     6760    +6     
  Misses         81       81           
  Partials       66       66           

Impacted Files	Coverage Δ
github/activity_notifications.go	94.59% <100.00%> (ø)
github/apps_manifest.go	100.00% <0.00%> (ø)
github/code-scanning.go	100.00% <0.00%> (ø)
github/repos_statuses.go	100.00% <0.00%> (ø)
github/users_gpg_keys.go	100.00% <0.00%> (ø)
github/github.go	97.15% <0.00%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a12f9cd...4bcc57b. Read the comment docs.

[willnorris]

so that's a lot of errors. I see that you have golangci-lint returning a 0 status, so this doesn't break builds. What's the plan then... a handful of follow-up PRs that address these individual errors, and then we eventually remove the --issues-exit-code=0? The other approach I've taken in the past is to just disable the failing linters, and then in the commits that fix the errors, also re-enable the linter.

We might also end up wanting to disable some of these, or at least for certain paths. For example, the dogsled errors in test files are probably not worth fixing. Same for the duplicate code detection. Our tests do duplicate some code and that's fine. Trying to refactor to remove the duplication is likely to make the tests less readable (at least in some cases).

[mmorel-35]

The --issues-exit-code=0 is to display the actual triggered warnings/errors without making the job failing indeed.
Then it's entirely up to you to decide what to do, if you want to remove a l'inter or just some rules indeed. So if you already have a method, I'll follow you.

[willnorris]

What about something like:

linters:
  # TODO: fix errors so that all of the linters below pass.
  # The linters that are commented out, as well as those explicitly disabled,
  # are currently failing.  We should fix those failures or define exclusion
  # rules, and then enable those linters.
  enable:
    - dogsled
    - dupl
    - gofmt
    - goimports
  # - gosec
    - misspell
    - nakedret
  # - stylecheck
  # - unconvert
  # - unparam
  # - whitespace
  disable:
    - errcheck
    - gosimple
    - staticcheck
    - ineffassign
    - unused
issues: 
  exclude-rules:
  - linters:
    - dogsled
    text:  "declaration has 3 blank identifiers"
    path: _test\.go
  - linters:
    - dupl
    path: _test\.go

then, as folks want to fix these, they can enable a specific linter locally, run golangci-lint to see what's failing, and fix those errors. That doesn't give us visibility in the CI logs of what is failing, but I think that's okay for now, especially since these won't take very long to fix.