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 > > >
