chore: Update golangci configuration

[kaymckay]

Linters we have chosen to disable because we get too many false positives:

• lll (line length)
• gomnd (magic numbers)

Funlen was changed from 100 -> 140 lines 50 -> 70 statements, and excludes comments.

List of added linters:

• bidichk
• contextcheck
• errorlint
• exportloopref
• goheader
• gomoddirectives
• makezero
• nilerr
• noctx
• tenv
• wsl
• govet - fieldalignment

A reference to all available linters if we want to add more : https://golangci-lint.run/usage/linters/

[codecov]

Codecov Report

Merging #234 (3e62e1b) into master (adee130) will decrease coverage by 0.01%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##           master     #234      +/-   ##
==========================================
- Coverage   97.18%   97.16%   -0.02%     
==========================================
  Files          53       53              
  Lines        5818     5816       -2     
==========================================
- Hits         5654     5651       -3     
- Misses        121      122       +1     
  Partials       43       43              

Impacted Files	Coverage Δ
database/build.go	100.00% <ø> (ø)
database/repo.go	100.00% <ø> (ø)
database/service.go	100.00% <ø> (ø)
database/step.go	100.00% <ø> (ø)
library/build.go	100.00% <ø> (ø)
library/hook.go	100.00% <ø> (ø)
library/login.go	100.00% <ø> (ø)
library/service.go	87.10% <ø> (ø)
library/step.go	100.00% <ø> (ø)
raw/map.go	93.10% <ø> (ø)
... and 15 more

[wass3r]

I get this when I try to run this locally inside this branch:

❯ golangci-lint version
golangci-lint has version 1.44.0 built from 617470f on 2022-01-25T11:22:07Z

❯ golangci-lint run    
WARN [runner] The linter 'golint' is deprecated (since v1.41.0) due to: The repository of the linter has been archived by the owner.  Replaced by revive. 
WARN [runner] The linter 'maligned' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.  Replaced by govet 'fieldalignment'. 
library/build.go:84:1: directive `// nolint:funlen // function length inflated due to number of env vars` is unused for linter "funlen" (nolintlint)
// nolint:funlen // function length inflated due to number of env vars
^
library/service.go:541:1: directive `// nolint: funlen // ignore function length due to comments and conditionals` is unused for linter "funlen" (nolintlint)
// nolint: funlen // ignore function length due to comments and conditionals
^
library/step.go:577:1: directive `// nolint: funlen // ignore function length due to comments and conditionals` is unused for linter "funlen" (nolintlint)
// nolint: funlen // ignore function length due to comments and conditionals
^

I think we want to take care of those deprecations and also remove the now unneeded nolint declarations.

I see the build is passing, but I found that it might actually be reporting incorrectly. I saw this in the logs (https://github.com/go-vela/types/runs/5116600489?check_suite_focus=true#step:4:76):

   level=error msg="Can't read config: can't read viper config: While parsing config: yaml: line 34: found unknown escape character"

I forgot that i modified the yaml prior to running this with the following change:

     exclude:
-      - "^\/\/"
+      - "^\\/\\/"

I think that would still ignore comments, but I didn't test to be honest.

[kaymckay]

Looking through the list of linters, I found a few that I don't think would hurt to add, but not sure if theres a reason we don't use them... I think there may be value in revisiting these

• asciicheck : simple linter to check that your code does not contain non-ASCII identifiers
• bidichk : checks for dangerous unicode character sequences
• contextcheck : check the function whether use a non-inherited context
• depguard : checks if package imports are in a list of acceptable packages
• gci : Gci control golang package import order and make it always deterministic
• gocritic : Provides diagnostics that check for bugs, performance and style issues.
  Extensible without recompilation through dynamic rules.
  Dynamic rules are written declaratively with AST patterns, filters, report message and optional suggestion.
• godox : Tool for detection of FIXME, TODO and other comment keywords - with this one I noticed we leave a lot of
  fixmes/todos in the release code
• goerr113 : Golang linter to check the errors handling expressions - this one doesn't like when we return new errors
• goheader : Checks is file header matches to pattern
• gomoddirectives : Manage the use of 'replace', 'retract', and 'excludes' directives in go.mod.
• ifshort : Checks that your code uses short syntax for if-statements whenever possible
• ireturn : Accept Interfaces, Return Concrete Types
• importas : Enforces consistent import aliases
• makezero : Finds slice declarations with non-zero initial length
• nilerr : Finds the code that returns nil even if it checks that the error is not nil.
• nilnil : Checks that there is no simultaneous return of nil error and an invalid value.
• noctx : noctx finds sending http request without context.Context
• prealloc : Finds slice declarations that could potentially be preallocated
• predeclared : find code that shadows one of Go's predeclared identifiers
• wastedassign : wastedassign finds wasted assignment statements
  testing checks I think could be useful as vela expands and we have strangers adding tests
• tenv : tenv is analyzer that detects using os.Setenv instead of t.Setenv since Go1.17
• thelper : thelper detects golang test helpers without t.Helper() call and checks the consistency of test helpers
• tparallel : tparallel detects inappropriate usage of t.Parallel() method in your Go test codes
  a full list of available linters: https://golangci-lint.run/usage/linters/

[wass3r]

i plan to look through them. i feel better about some of them than others. hoping to check some of their repos to get a better sense. thanks!

[kneal]

Would the plan be to update all repos with this change once it's in a good place?

[kaymckay]

@kneal correct

[wass3r]

asciicheck : simple linter to check that your code does not contain non-ASCII identifiers

seems non-critical? leaning towards no

bidichk : checks for dangerous unicode character sequences

sure

contextcheck : check the function whether use a non-inherited context

ok, i think?

depguard : checks if package imports are in a list of acceptable packages

i don't think we have a deny list, leaning towards no

gci : Gci control golang package import order and make it always deterministic

i don't know if we want to use this in particular, but i think keeping import order consistent would be nice

gocritic : Provides diagnostics that check for bugs, performance and style issues.
  Extensible without recompilation through dynamic rules.
  Dynamic rules are written declaratively with AST patterns, filters, report message and optional suggestion.

i'm good to try it, but a little apprehensive about the noise it might add

godox : Tool for detection of FIXME, TODO and other comment keywords - with this one I noticed we leave a lot of

i don't mind them personally, however i don't want to keep them forever either, so this would just add noise at the moment, i think

goerr113 : Golang linter to check the errors handling expressions - this one doesn't like when we return new errors

not sure if we're ready for this yet, but i think the premise is fine?

goheader : Checks is file header matches to pattern

this would be nice to ensure the license header is in place

gomoddirectives : Manage the use of 'replace', 'retract', and 'excludes' directives in go.mod.

don't feel strongly on this one, but might be handy in the future?

ifshort : Checks that your code uses short syntax for if-statements whenever possible

it's a stylistic thing. i guess consistency is nice. i believe we use both styles currently, but i don't generally favor one over the other myself.

ireturn : Accept Interfaces, Return Concrete Types

i think it's fine

importas : Enforces consistent import aliases

no, i feel like sometimes we want the flexibility to name imports as whatever and managing this via allow/deny lists is too painful

makezero : Finds slice declarations with non-zero initial length

fine by me

nilerr : Finds the code that returns nil even if it checks that the error is not nil.

yup

nilnil : Checks that there is no simultaneous return of nil error and an invalid value.

wonder if this would trip us up somewhere.. i'll defer

noctx : noctx finds sending http request without context.Context

sure, let's try

prealloc : Finds slice declarations that could potentially be preallocated

sure

predeclared : find code that shadows one of Go's predeclared identifiers

seems non-critical? leaning towards no

wastedassign : wastedassign finds wasted assignment statements

doesn't ineffassign and deadcode do similar?

tenv : tenv is analyzer that detects using os.Setenv instead of t.Setenv since Go1.17

sounds good to me

thelper : thelper detects golang test helpers without t.Helper() call and checks the consistency of test helpers

sounds like there false positives on this, prefer no at this point

tparallel : tparallel detects inappropriate usage of t.Parallel() method in your Go test codes

sounds like there false positives on this, prefer no at this point

[wass3r]

i would also like to propose to add wsl (currently not enabled).. i know it can be noisy, but i like that spacing and selfishly it's nicer to jump around in code (with Vim for example)

btw, thanks for adding comments next to the linters!

[wass3r]

with maligned removed, we can get rid of this setting i believe. i think we have to add a govet setting instead to do the fieldalignment?

[kaymckay]

i'll add, with reference to wsl above ^^, what about adding nlreturn? -- checks for a new line before return and branch statements to increase code clarity

[wass3r]

honestly, i thought wsl took care of that, but if it doesn't i'm in favor of adding it

[wass3r]

not sure how others feel, but i'm personally in favor of removing this one (godot). sometimes it makes you throw a period in odd places

.

[kneal]

I honestly like godot I think it does a really good job at ensure consistency with some of the docs. If we didn't have I'm willing to bet we'd have some sentences with periods and some without in the godocs.

[wass3r]

k, i mostly don't like it when it forces one when it doesn't make sense, otherwise it's fine

[wass3r]

for example:

https://github.com/go-vela/server/blob/09c50c25579da62c620ca3c44789baa8f7f42fb5/router/build.go#L44

[kneal]

Yeah that's super awkward but I'm guessing the parser is pretty stupid in that case and just looks at the whole comment block. 😢

[kaymckay]

Taking this updated list and testing it against a few other repos to check for any major issues

[kneal]

Very true, honestly. So, maybe we put a pin it, with an issue?

[wass3r]

@kneal an issue would be great! i can't promise i will remember otherwise myself :)

[kneal]

Got you fam go-vela/community#501

[kaymckay]

removed a few that caused too much noise or was just a style preference that we didn't seem to follow.

as for fieldalignment , I have to remove govet from tests to remove the fieldalignment calling out misordered structs...

• I cleaned this repo to pass fieldalignment - you can see how much it changes the structs, plan to keep/remove that commit based on this discussion

If we don't care about this micro performance enhancement and like the order of the structs as they are, I suggest removing the fieldalignment all together or else we will get a lot of false positives.

[wass3r]

looks like with the current config it wants a space before the return here:

types/database/build.go

Lines 83 to 84 in 850d896

	}
	return b

[wass3r]

Thanks @kaymckay - i'd be interested to hear others' thoughts on fieldalignment (previously maligned). seems overkill for tests to me. outside of that, i'm a bit on the fence. i guess it was enabled before but i don't really recall it yelling at us too much.

[jbrockopp]

@kaymckay @wass3r

My thoughts on fieldalignment are we should definitely consider ignoring this linter for test files 😅

As far as do we want to use this linter or not in general, I'm on the fence.

On the one hand, the linter does offer performance improvements from a memory consumption perspective:

https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/fieldalignment

On the other hand, I seriously question to what extent we'll see improvements (how much?) from sorting structs 😃

If I had to choose, I guess I'd lean towards using fieldalignment under the guise that "every little bit helps"?

If someone can provide thoughts on why not to use it, I'm all ears because my argument to use it is weak 👍

cc: @kneal

[kneal]

fieldalignment can't say I have strong feelings about. Personally, I've always tried to list things alphabetically or logically to how the fields are being used for sanity. Honestly, I'm not sure I have a strong preference on it. I can't tell if this affects struct field ordering or just fields when you're calling a struct.

I know some struct field ordering we likely wouldn't want change, the YAML structs are an example because the way the struct is laid out plays some role in the auto-generation of a YAML file or maybe we don't care. I don't know.

[wass3r]

i think we can summarize that we don't feel strongly about the gains, so let's table it and skip for now :)

[kaymckay]

waiting on approval to proceed with other repos

[KellyMerrick]

lgtm

[kneal]

LGTM 🐬