eeafj/golangci-lint
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity

point users to --new-from-rev=HEAD~ for CI setups in --help

Browse Source 
Although the FAQ does eventually mention that
--new-from-rev=origin/master is the right way, --help does not and
using --new in CI is a terrible pitfall.

Make --help point users to -new-from-rev=HEAD~ for CI setups.

Also use HEAD~ instead of origin/master, since HEAD~ is more
universally applicable, e.g. if golangci-lint is ran against a release
branch.
This commit is contained in:
Romanos Skiadas 2018-08-07 10:15:53 +01:00 committed by Isaev Denis
parent a2450a5281
commit d3eb3ed74d
3 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@ -387,7 +387,8 @@ Flags:
--max-same-issues int Maximum count of issues with the same text. Set to 0 to disable (default 3)
-n, --new Show only new issues: if there are unstaged changes or untracked files, only those changes are analyzed, else only changes in HEAD~ are analyzed.
It's a super-useful option for integration of golangci-lint into existing large codebase.
It's not practical to fix all existing issues at the moment of integration: much better don't allow issues in new code
It's not practical to fix all existing issues at the moment of integration: much better to not allow issues in new code.
For CI setups, prefer --new-from-rev=HEAD~, as --new can skip linting the current patch if any scripts generate unstaged files before golangci-lint runs.
--new-from-rev REV Show only new issues created after git revision REV
--new-from-patch PATH Show only new issues created in git patch with file path PATH
-h, --help help for run
@ -671,7 +672,7 @@ You can integrate it yourself, see this [wiki page](https://github.com/golangci/
**It's cool to use `golangci-lint` when starting a project, but what about existing projects with large codebase? It will take days to fix all found issues**
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 (or better use [GolangCI](https://golangci.com) to run `golangci-lint` with option `--new-from-rev=origin/master`. Also, take a look at option `-n`.
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 (or better use [GolangCI](https://golangci.com)) 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).
**How to use `golangci-lint` in CI (Continuous Integration)?**

2
README.tmpl.md
View File

@ -327,7 +327,7 @@ You can integrate it yourself, see this [wiki page](https://github.com/golangci/
**It's cool to use `golangci-lint` when starting a project, but what about existing projects with large codebase? It will take days to fix all found issues**
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 (or better use [GolangCI](https://golangci.com) to run `golangci-lint` with option `--new-from-rev=origin/master`. Also, take a look at option `-n`.
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 (or better use [GolangCI](https://golangci.com)) 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).
**How to use `golangci-lint` in CI (Continuous Integration)?**

4
pkg/commands/run.go
View File

@ -153,7 +153,9 @@ func initFlagSet(fs *pflag.FlagSet, cfg *config.Config) {
wh("Show only new issues: if there are unstaged changes or untracked files, only those changes "+
"are analyzed, else only changes in HEAD~ are analyzed.\nIt's a super-useful option for integration "+
"of golangci-lint into existing large codebase.\nIt's not practical to fix all existing issues at "+
"the moment of integration: much better don't allow issues in new code"))
"the moment of integration: much better to not allow issues in new code.\nFor CI setups, prefer "+
"--new-from-rev=HEAD~, as --new can skip linting the current patch if any scripts generate "+
"unstaged files before golangci-lint runs."))
fs.StringVar(&ic.DiffFromRevision, "new-from-rev", "",
wh("Show only new issues created after git revision `REV`"))
fs.StringVar(&ic.DiffPatchFilePath, "new-from-patch", "",