Table of Contents
We are sure that every project can easily integrate
golangci-lint, even the large one. The idea is to not fix all existing issues. Fix only newly added issue: issues in new code. To do this setup CI to run
golangci-lint with option
--new-from-rev=HEAD~1. Also, take a look at option
--new, but consider that CI scripts that generate unstaged files will make
--new only point out issues in those files and not in the last commit. In that regard
--new-from-rev=HEAD~1 is safer.
By doing this you won't create new issues in your code and can choose fix existing issues (or not).
golangci-lint in CI and check the exit code. If it's non-zero - fail the build.
The same as the Go team (the 2 last minor versions)
- Please, ensure you are using the latest binary release.
- Run it with
-voption and check the output.
- If it doesn't help create a GitHub issue with the output from the error and #2 above.
Because the first run caches type information. All subsequent runs will be fast. Usually this options is used during development on local machine and compilation was already performed.
typecheck is like the front-end of a Go compiler, parses and type-checks Go code, it manages compilation errors.
It cannot be disabled because of that.
Of course, this is just as good as the compiler itself and a lot of compilation issues will not properly show where in the code your error lies.
typecheck is not a real linter, it's just a way to parse compiling errors (produced by the
types.Checker) and some linter errors.
If there are
typecheck errors, golangci-lint will not able to produce other reports because that kind of error doesn't allow it to perform analysis.
How to troubleshoot:
- Ensure the version of
golangci-lintis built with a compatible version of Go.
- Ensure dependencies are up-to-date with
go mod tidy.
- Ensure building works with
go run ./.../
go build ./...- whole package.
- If using CGO, ensure all require system libraries are installed.