| Age | Commit message (Collapse) | Author |
|---|
|
Back in ce3f2ee42 (Lint: split up "make lint" and "make lint-strict"
configs, 2021-01-19), we have split up our linting rules into a "normal"
set which needs to be satisfied for each CI run and a "strict" set which
only runs on scheduled pipelines. I highly doubt that anybody ever takes
a look at the strict linter job: there are no MRs which clean up any of
its additional violations.
Let's remove this job and be done with it. Anybody wishing to fix up
linting rules can just play with our normal linting rules and is
unlikely to use CI for this anyway.
|
|
We can turn this on by default by being a bit more permissive about
common cases in non-*_test.go files that should be OK not to check the
return value of most of the time (e.g. os.Remove()), and then having a
giant exclusions list for the rest.
|
|
Since we've got quite a common warning about things needing comments,
add a gigantic list of those exclusions. Generated with:
make lint |grep golint | sort
| perl -pe 's/^(.*?):\d+:\d\s*golint\s*(.*)/ - linters: \n - golint\n path: "$1"\n text: "$2"/g'
Except I then had to escape "(" in the text to "\\(" because they're
regexes. I suggested simply turning this specific warning off, but
others in today's team meeting wanted to keep it. So here it is as a
giant list.
|
|
This reverts & amends commit 0b5a8ea8e (disable gochecknoglobals
linter, 2020-12-17).
We can just exclude the feature variables from the complaining. This
leaves a manageable amount of issues which we can add to "make
lint-strict".
|
|
Take a different approach than 20ef26439 (golangci: Enable error and
documentation linters, 2020-12-17) did and get rid of "new-from-rev"
entirely.
Instead we have config for "make lint-strict" which isn't passing yet,
and the main config for "make lint" which'll cause a CI failure.
After looking a bit into how "new-from-rev" works I think using it is
just a fundamentally bad idea in our case. All we want is to phase-in
new lints, which we can just do better like this with a new config.
To figure out what lines to complain about since "b7d42677f" it has to
run:
git diff --relative b7d42677f
Which currently takes ~200ms for me, but that relatively short time is
because it's ~300 commits ago.
If we take something ~3000 commits ago (early 2020, so not that long)
like "1e3d3131f" it's going to take ~3 seconds, and worse we're
starting to run into the default diff.renameLimit there, so the diff
will suddenly get much worse. So the whole thing is a ticking timebomb
in behavior & gradual slowdown waiting to happen.
|
