Having used golangci-lint a bit, I can tell you that it's configurable to disable individual checkers via a config file and is quite fast. I'm of the opinion that having the redundancy might be an issue if it were inefficient, but it's not and these linters are likely to evolve over a short time..
I'm definitely +1 on at least exploring this tool for ATC. -dan On Mon, Sep 30, 2019 at 3:10 PM Hoppal, Michael <[email protected]> wrote: > Great input! I think the beauty of golangci-lint is we can organically > iterate overtime and easily define the right set of linters that we want to > use all while keeping consistent output formatting that is easily > consumable by Jenkins. > > If we think there is too much overlap in the defaults we could pair it > down to something more like: > > * govet > * errcheck > * ineffassign > * gofmt > > Thanks, > > Michael > > On 9/30/19, 2:29 PM, "ocket 8888" <[email protected]> wrote: > > Let me start by saying I'm all for a linter for the Go codebase(s). > > This collection of linters seems to have a lot of redundancy, and be > built > with using their specific CI platform in mind. In just the default > linters > it lists, it has four or five different linters to check for unused > code, > something that is performed already by the compiler (type checking), > and > both "govet" and something that describes itself as "govet on > steroids". So > I wonder if maybe we want to pick something smaller and less redundant. > > On Mon, Sep 30, 2019 at 8:28 AM Hoppal, Michael < > [email protected]> > wrote: > > > Hi, > > > > As we grow our Golang footprint within ATC we should consider the > addition > > of a linter for our CI. > > > > As with any linter it provides a lot of benefits including enforcing > a > > consistent style, early detection of potential bugs and speed up of > PR > > reviews. > > > > That being said I propose that we add the linter GoLangCI-Lint< > > https://github.com/golangci/golangci-lint> to our CI. It wraps many > > widely used linters in the Golang opensource community with the > ability to > > turn on which ones are run. It also supports outputting results in > > checkstyle which is consumable via Jenkins for a visual report. > > > > To start I would recommend to stay with the default enabled linters< > > https://github.com/golangci/golangci-lint#enabled-by-default-linters> > on > > the tool with the addition of Gofmt. > > > > The roll out path (up for discussion of course) would be: > > > > > > * Makefile target within the source code to allow developers to > run > > the linting locally as they develop > > * Inclusion of GolangCI-Lint within CI as a non-voting component > on > > every PR (as to not block development when turned on) > > * Fixing of the current lint violations > > * Make the linting a blocking voting component of CI > > > > What are peoples thoughts on the inclusion of linting in general, > choice > > of linter and the outlined rollout plan? > > > > Thanks, > > > > Michael Hoppal > > > > > > > > >
