Okay, the bit about consistent output formatting is a good point. I suppose any of my concerns are best addressed in the configuration, really. +1
On Tue, Oct 1, 2019, 08:53 Jeremy Mitchell <[email protected]> wrote: > As a Go noob, I defer to the experts... > > On Mon, Sep 30, 2019 at 9:05 PM Dan Kirkwood <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > >
