Skip to content

docs: update GitHub Action assets #4589

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 28, 2024
Merged

docs: update GitHub Action assets #4589

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion assets/cli-help.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
{
"enable": "Enabled by default linters:\nerrcheck: errcheck is a program for checking for unchecked errors in Go code. These unchecked errors can be critical bugs in some cases [fast: false, auto-fix: false]\ngosimple (megacheck): Linter for Go source code that specializes in simplifying code [fast: false, auto-fix: false]\ngovet (vet, vetshadow): Vet examines Go source code and reports suspicious constructs. It is roughly the same as 'go vet' and uses its passes. [fast: false, auto-fix: false]\nineffassign: Detects when assignments to existing variables are not used [fast: true, auto-fix: false]\nstaticcheck (megacheck): It's a set of rules from staticcheck. It's not the same thing as the staticcheck binary. The author of staticcheck doesn't support or approve the use of staticcheck as a library inside golangci-lint. [fast: false, auto-fix: false]\nunused (megacheck): Checks Go code for unused constants, variables, functions and types [fast: false, auto-fix: false]",
"help": "Usage:\n golangci-lint run [flags]\n\nFlags:\n -c, --config PATH Read config from file path PATH\n --no-config Don't read config file\n -D, --disable strings Disable specific linter\n --disable-all Disable all linters\n -E, --enable strings Enable specific linter\n --enable-all Enable all linters\n --fast Enable only fast linters from enabled linters set (first run won't be fast)\n -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\n --enable-only strings Override linters configuration section to only run the specific linter(s)\n -j, --concurrency int Number of CPUs to use (Default: number of logical CPUs) (default 8)\n --modules-download-mode string Modules download mode. If not empty, passed as -mod=\u003cmode\u003e to go tools\n --issues-exit-code int Exit code when issues were found (default 1)\n --go string Targeted Go version\n --build-tags strings Build tags\n --timeout duration Timeout for total work (default 1m0s)\n --tests Analyze tests (*_test.go) (default true)\n --allow-parallel-runners Allow multiple parallel golangci-lint instances running. If false (default) - golangci-lint acquires file lock on start.\n --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.\n --out-format string Formats of output: colored-line-number|line-number|json|tab|checkstyle|code-climate|html|junit-xml|github-actions|teamcity (default \"colored-line-number\")\n --print-issued-lines Print lines of code with issue (default true)\n --print-linter-name Print linter name in issue line (default true)\n --uniq-by-line Make issues output unique by line (default true)\n --sort-results Sort linter results\n --sort-order strings Sort order of linter results\n --path-prefix string Path prefix to add to output\n --show-stats Show statistics per linter\n -e, --exclude strings Exclude issue by regexp\n --exclude-use-default Use or not use default excludes:\n # EXC0001 errcheck: Almost all programs ignore errors on these functions and in most cases it's ok\n - Error return value of .((os\\.)?std(out|err)\\..*|.*Close|.*Flush|os\\.Remove(All)?|.*print(f|ln)?|os\\.(Un)?Setenv). is not checked\n \n # EXC0002 golint: Annoying issue about not having a comment. The rare codebase has such comments\n - (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)\n \n # EXC0003 golint: False positive when tests are defined in package 'test'\n - func name will be used as test\\.Test.* by other packages, and that stutters; consider calling this\n \n # EXC0004 govet: Common false positives\n - (possible misuse of unsafe.Pointer|should have signature)\n \n # EXC0005 staticcheck: Developers tend to write in C-style with an explicit 'break' in a 'switch', so it's ok to ignore\n - ineffective break statement. Did you mean to break out of the outer loop\n \n # EXC0006 gosec: Too many false-positives on 'unsafe' usage\n - Use of unsafe calls should be audited\n \n # EXC0007 gosec: Too many false-positives for parametrized shell calls\n - Subprocess launch(ed with variable|ing should be audited)\n \n # EXC0008 gosec: Duplicated errcheck checks\n - (G104)\n \n # EXC0009 gosec: Too many issues in popular repos\n - (Expect directory permissions to be 0750 or less|Expect file permissions to be 0600 or less)\n \n # EXC0010 gosec: False positive is triggered by 'src, err := ioutil.ReadFile(filename)'\n - Potential file inclusion via variable\n \n # EXC0011 stylecheck: Annoying issue about not having a comment. The rare codebase has such comments\n - (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)\n \n # EXC0012 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - exported (.+) should have comment( \\(or a comment on this block\\))? or be unexported\n \n # EXC0013 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - package comment should be of the form \"(.+)...\n \n # EXC0014 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - comment on exported (.+) should be of the form \"(.+)...\"\n \n # EXC0015 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - should have a package comment\n (default true)\n --exclude-case-sensitive If set to true exclude and exclude rules regular expressions are case-sensitive\n --max-issues-per-linter int Maximum issues count per one linter. Set to 0 to disable (default 50)\n --max-same-issues int Maximum count of issues with the same text. Set to 0 to disable (default 3)\n --exclude-files strings Regexps of files to exclude\n --exclude-dirs strings Regexps of directories to exclude\n --exclude-dirs-use-default Use or not use default excluded directories:\n - (^|/)vendor($|/)\n - (^|/)third_party($|/)\n - (^|/)testdata($|/)\n - (^|/)examples($|/)\n - (^|/)Godeps($|/)\n - (^|/)builtin($|/)\n (default true)\n -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.\n It's a super-useful option for integration of golangci-lint into existing large codebase.\n It's not practical to fix all existing issues at the moment of integration: much better to not allow issues in new code.\n 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.\n --new-from-rev REV Show only new issues created after git revision REV\n --new-from-patch PATH Show only new issues created in git patch with file path PATH\n --whole-files Show issues in any part of update files (requires new-from-rev or new-from-patch)\n --fix Fix found issues (if it's supported by the linter)\n --cpu-profile-path string Path to CPU profile output file\n --mem-profile-path string Path to memory profile output file\n --print-resources-usage Print avg and max memory usage of golangci-lint and total time\n --trace-path string Path to trace output file\n\nGlobal Flags:\n --color string Use color when printing; can be 'always', 'auto', or 'never' (default \"auto\")\n -h, --help Help for a command\n -v, --verbose Verbose output\n"
"help": "Usage:\n golangci-lint run [flags]\n\nFlags:\n -c, --config PATH Read config from file path PATH\n --no-config Don't read config file\n -D, --disable strings Disable specific linter\n --disable-all Disable all linters\n -E, --enable strings Enable specific linter\n --enable-all Enable all linters\n --fast Enable only fast linters from enabled linters set (first run won't be fast)\n -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\n --enable-only strings Override linters configuration section to only run the specific linter(s)\n -j, --concurrency int Number of CPUs to use (Default: number of logical CPUs) (default 8)\n --modules-download-mode string Modules download mode. If not empty, passed as -mod=\u003cmode\u003e to go tools\n --issues-exit-code int Exit code when issues were found (default 1)\n --go string Targeted Go version\n --build-tags strings Build tags\n --timeout duration Timeout for total work (default 1m0s)\n --tests Analyze tests (*_test.go) (default true)\n --allow-parallel-runners Allow multiple parallel golangci-lint instances running. If false (default) - golangci-lint acquires file lock on start.\n --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.\n --out-format string Formats of output: json|line-number|colored-line-number|tab|colored-tab|checkstyle|code-climate|html|junit-xml|github-actions|teamcity (default \"colored-line-number\")\n --print-issued-lines Print lines of code with issue (default true)\n --print-linter-name Print linter name in issue line (default true)\n --uniq-by-line Make issues output unique by line (default true)\n --sort-results Sort linter results\n --sort-order strings Sort order of linter results\n --path-prefix string Path prefix to add to output\n --show-stats Show statistics per linter\n -e, --exclude strings Exclude issue by regexp\n --exclude-use-default Use or not use default excludes:\n # EXC0001 errcheck: Almost all programs ignore errors on these functions and in most cases it's ok\n - Error return value of .((os\\.)?std(out|err)\\..*|.*Close|.*Flush|os\\.Remove(All)?|.*print(f|ln)?|os\\.(Un)?Setenv). is not checked\n \n # EXC0002 golint: Annoying issue about not having a comment. The rare codebase has such comments\n - (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)\n \n # EXC0003 golint: False positive when tests are defined in package 'test'\n - func name will be used as test\\.Test.* by other packages, and that stutters; consider calling this\n \n # EXC0004 govet: Common false positives\n - (possible misuse of unsafe.Pointer|should have signature)\n \n # EXC0005 staticcheck: Developers tend to write in C-style with an explicit 'break' in a 'switch', so it's ok to ignore\n - ineffective break statement. Did you mean to break out of the outer loop\n \n # EXC0006 gosec: Too many false-positives on 'unsafe' usage\n - Use of unsafe calls should be audited\n \n # EXC0007 gosec: Too many false-positives for parametrized shell calls\n - Subprocess launch(ed with variable|ing should be audited)\n \n # EXC0008 gosec: Duplicated errcheck checks\n - (G104)\n \n # EXC0009 gosec: Too many issues in popular repos\n - (Expect directory permissions to be 0750 or less|Expect file permissions to be 0600 or less)\n \n # EXC0010 gosec: False positive is triggered by 'src, err := ioutil.ReadFile(filename)'\n - Potential file inclusion via variable\n \n # EXC0011 stylecheck: Annoying issue about not having a comment. The rare codebase has such comments\n - (comment on exported (method|function|type|const)|should have( a package)? comment|comment should be of the form)\n \n # EXC0012 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - exported (.+) should have comment( \\(or a comment on this block\\))? or be unexported\n \n # EXC0013 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - package comment should be of the form \"(.+)...\n \n # EXC0014 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - comment on exported (.+) should be of the form \"(.+)...\"\n \n # EXC0015 revive: Annoying issue about not having a comment. The rare codebase has such comments\n - should have a package comment\n (default true)\n --exclude-case-sensitive If set to true exclude and exclude rules regular expressions are case-sensitive\n --max-issues-per-linter int Maximum issues count per one linter. Set to 0 to disable (default 50)\n --max-same-issues int Maximum count of issues with the same text. Set to 0 to disable (default 3)\n --exclude-files strings Regexps of files to exclude\n --exclude-dirs strings Regexps of directories to exclude\n --exclude-dirs-use-default Use or not use default excluded directories:\n - (^|/)vendor($|/)\n - (^|/)third_party($|/)\n - (^|/)testdata($|/)\n - (^|/)examples($|/)\n - (^|/)Godeps($|/)\n - (^|/)builtin($|/)\n (default true)\n -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.\n It's a super-useful option for integration of golangci-lint into existing large codebase.\n It's not practical to fix all existing issues at the moment of integration: much better to not allow issues in new code.\n 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.\n --new-from-rev REV Show only new issues created after git revision REV\n --new-from-patch PATH Show only new issues created in git patch with file path PATH\n --whole-files Show issues in any part of update files (requires new-from-rev or new-from-patch)\n --fix Fix found issues (if it's supported by the linter)\n --cpu-profile-path string Path to CPU profile output file\n --mem-profile-path string Path to memory profile output file\n --print-resources-usage Print avg and max memory usage of golangci-lint and total time\n --trace-path string Path to trace output file\n\nGlobal Flags:\n --color string Use color when printing; can be 'always', 'auto', or 'never' (default \"auto\")\n -h, --help Help for a command\n -v, --verbose Verbose output\n"
}
Loading
Loading