How do you think the linter process would integrate with our existing ./pkg
wrapper if at all?
Jonathan G
On 10/1/19, 10:24 AM, "Rawlin Peters" <rawlin.pet...@gmail.com> wrote:
+1, I'm generally in favor of shared linters and formatters where
possible, and that rollout path sounds good to me.
- Rawlin
On Mon, Sep 30, 2019 at 8:28 AM Hoppal, Michael
<michael_hop...@comcast.com> 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
>
>
