golangci-lint源码解析-如何从源码查看有哪些命令行参数及如何使用

1. 背景

golangci-lint的官方文档和golangci-lint help命令对命令行参数的说明都不完善，升级了golangci-lint之后，之前的--skip-files参数不可用了，通过官网和help命令查询新的应该怎么配，返回的不直观，可以通过查看源码，查询有哪些参数

$golangci-lint run --help                  
Run the linters

Usage:
  golangci-lint run [flags]

Flags:
  -c, --config PATH                    Read config from file path PATH
      --no-config                      Don't read config file
  -D, --disable strings                Disable specific linter
      --disable-all                    Disable all linters
  -E, --enable strings                 Enable specific linter
      --enable-all                     Enable all linters
      --fast                           Enable only fast linters from enabled linters set (first run won't be fast)
  -p, --presets strings                Enable presets (bugs|comment|complexity|error|format|import|metalinter|module|performance|sql|style|test|unused) of linters.
                                       Run 'golangci-lint help linters' to see them.
                                       This option implies option --disable-all
      --enable-only strings            Override linters configuration section to only run the specific linter(s)
  -j, --concurrency int                Number of CPUs to use (Default: number of logical CPUs) (default 12)
      --modules-download-mode string   Modules download mode. If not empty, passed as -mod=<mode> to go tools
      --issues-exit-code int           Exit code when issues were found (default 1)
      --go string                      Targeted Go version
      --build-tags strings             Build tags
      --timeout duration               Timeout for total work (default 1m0s)
      --tests                          Analyze tests (*_test.go) (default true)
      --allow-parallel-runners         Allow multiple parallel golangci-lint instances running.
                                       If false (default) - golangci-lint acquires file lock on start.
      --allow-serial-runners           Allow multiple golangci-lint instances running, but serialize them around a lock.
                                       If false (default) - golangci-lint exits with an error if it fails to acquire file lock on start.
      --out-format string              Formats of output: json|line-number|colored-line-number|tab|colored-tab|checkstyle|code-climate|html|junit-xml|junit-xml-extended|github-actions|teamcity|sarif (default "colored-line-number")
      --print-issued-lines             Print lines of code with issue (default true)
      --print-linter-name              Print linter name in issue line (default true)
      --uniq-by-line                   Make issues output unique by line (default true)
      --sort-results                   Sort linter results
      --sort-order strings             Sort order of linter results
      --path-prefix string             Path prefix to add to output
      --show-stats                     Show statistics per linter
  -e, --exclude strings                Exclude issue by regexp
      --exclude-use-default            Use or not use default excludes:
                                         - EXC0001 (errcheck): Almost all programs ignore errors on these functions and in most cases it's ok.
                                           Pattern: 'Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*print(f|ln)?|os\.(Un)?Setenv). is not checked'
                                         - EXC0002 (golint): Annoying issue about not having a comment. The rare codebase has such comments.
                                           Pattern: '(comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)'
                                         - EXC0003 (golint): False positive when tests are defined in package 'test'.
                                           Pattern: 'func name will be used as test\.Test.* by other packages, and that stutters; consider calling this'
                                         - EXC0004 (govet): Common false positives.
                                           Pattern: '(possible misuse of unsafe.Pointer|should have signature)'
                                         - EXC0005 (staticcheck): Developers tend to write in C-style with an explicit 'break' in a 'switch', so it's ok to ignore.
                                           Pattern: 'SA4011'
                                         - EXC0006 (gosec): Too many false-positives on 'unsafe' usage.
                                           Pattern: 'G103: Use of unsafe calls should be audited'
                                         - EXC0007 (gosec): Too many false-positives for parametrized shell calls.
                                           Pattern: 'G204: Subprocess launched with variable'
                                         - EXC0008 (gosec): Duplicated errcheck checks.
                                           Pattern: 'G104'
                                         - EXC0009 (gosec): Too many issues in popular repos.
                                           Pattern: '(G301|G302|G307): Expect (directory permissions to be 0750|file permissions to be 0600) or less'
                                         - EXC0010 (gosec): False positive is triggered by 'src, err := ioutil.ReadFile(filename)'.
                                           Pattern: 'G304: Potential file inclusion via variable'
                                         - EXC0011 (stylecheck): Annoying issue about not having a comment. The rare codebase has such comments.
                                           Pattern: '(ST1000|ST1020|ST1021|ST1022)'
                                         - EXC0012 (revive): Annoying issue about not having a comment. The rare codebase has such comments.
                                           Pattern: 'exported (.+) should have comment( \(or a comment on this block\))? or be unexported'
                                         - EXC0013 (revive): Annoying issue about not having a comment. The rare codebase has such comments.
                                           Pattern: 'package comment should be of the form "(.+)..."'
                                         - EXC0014 (revive): Annoying issue about not having a comment. The rare codebase has such comments.
                                           Pattern: 'comment on exported (.+) should be of the form "(.+)..."'
                                         - EXC0015 (revive): Annoying issue about not having a comment. The rare codebase has such comments.
                                           Pattern: 'should have a package comment' (default true)
      --exclude-case-sensitive         If set to true exclude and exclude rules regular expressions are case-sensitive
      --max-issues-per-linter int      Maximum issues count per one linter. Set to 0 to disable (default 50)
      --max-same-issues int            Maximum count of issues with the same text. Set to 0 to disable (default 3)
      --exclude-files strings          Regexps of files to exclude
      --exclude-dirs strings           Regexps of directories to exclude
      --exclude-dirs-use-default       Use or not use default excluded directories:
                                         - (^|/)vendor($|/)
                                         - (^|/)third_party($|/)
                                         - (^|/)testdata($|/)
                                         - (^|/)examples($|/)
                                         - (^|/)Godeps($|/)
                                         - (^|/)builtin($|/)
                                        (default true)
      --exclude-generated string       Mode of the generated files analysis (default "lax")
  -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 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
      --whole-files                    Show issues in any part of update files (requires new-from-rev or new-from-patch)
      --fix                            Fix found issues (if it's supported by the linter)
      --cpu-profile-path string        Path to CPU profile output file
      --mem-profile-path string        Path to memory profile output file
      --print-resources-usage          Print avg and max memory usage of golangci-lint and total time
      --trace-path string              Path to trace output file

Global Flags:
      --color string   Use color when printing; can be 'always', 'auto', or 'never' (default "auto")
  -h, --help           Help for a command
  -v, --verbose        Verbose output

2. 入口

所有的命令行入口都在pkg/commands下

3. run配置项

3.1. 排除文件的选项