poor performance for golangci-lint v1.61 and go 1.23
shiyuhang0 opened this issue · 3 comments
shiyuhang0 commented
Welcome
- Yes, I understand that the GitHub action repository is not the repository of golangci-lint itself.
- Yes, I've searched similar issues on GitHub and didn't find any.
- Yes, I've included all information below (version, config, etc).
Description of the problem
I find the action takes 15min when I use golangco-lint v1.61 and go 1.23. Before, it takes 5 min for golangco-lint v1.58 and go 1.22.
Version of golangci-lint
1.61
Version of the GitHub Action
v6
Workflow file
- name: golangci lint
uses: golangci/golangci-lint-action@v6
with:
version: v1.61.0
args: --verbose
skip-pkg-cache: true # use manual cache instead
skip-build-cache: true # use manual cache insteadGolangci-lint configuration
# This file contains all available configuration options
# with their default values.
# options for analysis running
run:
# default concurrency is a available CPU number
concurrency: 4
# timeout for analysis, e.g. 30s, 5m, default is 1m
timeout: 20m
# exit code when at least one issue was found, default is 1
issues-exit-code: 1
# include test files or not, default is true
tests: true
# list of build tags, all linters use it. Default is empty list.
# build-tags:
# - mytag
# by default isn't set. If set we pass it to "go list -mod={option}". From "go help modules":
# If invoked with -mod=readonly, the go command is disallowed from the implicit
# automatic updating of go.mod described above. Instead, it fails when any changes
# to go.mod are needed. This setting is most useful to check that go.mod does
# not need updates, such as in a continuous integration and testing system.
# If invoked with -mod=vendor, the go command assumes that the vendor
# directory holds the correct copies of dependencies and ignores
# the dependency descriptions in go.mod.
# modules-download-mode:
# output configuration options
output:
# print lines of code with issue, default is true
print-issued-lines: true
# print linter name in the end of issue text, default is true
print-linter-name: true
# all available settings of specific linters
linters-settings:
govet:
disable:
- printf
errcheck:
# report about not checking of errors in type assetions: `a := b.(MyStruct)`;
# default is false: such cases aren't reported by default.
check-type-assertions: false
# report about assignment of errors to blank identifier: `num, _ := strconv.Atoi(numStr)`;
# default is false: such cases aren't reported by default.
check-blank: false
gofmt:
# simplify code: gofmt with `-s` option, true by default
simplify: true
gocyclo:
# minimal code complexity to report, 30 by default (but we recommend 10-20)
min-complexity: 10
goconst:
# minimal length of string constant, 3 by default
min-len: 3
# minimal occurrences count to trigger, 3 by default
min-occurrences: 3
misspell:
# Correct spellings using locale preferences for US or UK.
# Default is to use a neutral variety of English.
# Setting locale to US will correct the British spelling of 'colour' to 'color'.
locale: US
lll:
# max line length, lines longer will be reported. Default is 120.
# '\t' is counted as 1 character by default, and can be changed with the tab-width option
line-length: 120
# tab width in spaces. Default to 1.
tab-width: 1
nakedret:
# make an issue if func has more lines of code than this setting and it has naked returns; default is 30
max-func-lines: 30
gocritic:
# Which checks should be enabled; can't be combined with 'disabled-checks';
# See https://go-critic.github.io/overview#checks-overview
# To check which checks are enabled run `GL_DEBUG=gocritic golangci-lint run`
# By default list of stable checks is used.
# enabled-checks:
# - rangeValCopy
# Which checks should be disabled; can't be combined with 'enabled-checks'; default is empty
disabled-checks:
- regexpMust
# Enable multiple checks by tags, run `GL_DEBUG=gocritic golangci-lint` run to see all tags and checks.
# Empty list by default. See https://github.com/go-critic/go-critic#usage -> section "Tags".
enabled-tags:
- performance
settings: # settings passed to gocritic
captLocal: # must be valid enabled check name
paramsOnly: true
rangeValCopy:
sizeThreshold: 32
revive:
# see https://github.com/mgechev/revive#available-rules for details.
ignore-generated-header: false
severity: error
rules:
- name: error-return
- name: error-strings
- name: error-naming
- name: if-return
- name: range
- name: receiver-naming
- name: indent-error-flow
- name: superfluous-else
- name: modifies-parameter
- name: deep-exit
- name: unreachable-code
- name: time-naming
- name: errorf
- name: context-keys-type
gosec:
# To select a subset of rules to run.
# Available rules: https://github.com/securego/gosec#available-rules
includes:
- G103
- G204
- G304
- G307
- G505
exclude-generated: true
severity: "high"
confidence: "low"
linters:
disable-all: true
enable: # sort the linters alphabetically
- asciicheck
# - bodyclose
# - depguard
# - durationcheck
- errcheck
# - errorlint
# - exhaustive
- exportloopref
- goconst
# - gocritic
- gofmt
- goimports
- gosec
- gosimple
- govet
- ineffassign
- makezero
- misspell
# - nakedret
# - nilerr
# - noctx
- revive
# - rowserrcheck
# - sqlclosecheck
- staticcheck
- typecheck
- unconvert
- unused
fast: false
issues:
# List of regexps of issue texts to exclude, empty list by default.
# But independently from this option we use default exclude patterns,
# it can be disabled by `exclude-use-default: false`. To list all
# excluded by default patterns execute `golangci-lint run --help`
exclude:
- abcdef
- 'error-strings: error strings should not be capitalized or end with punctuation or a newline'
exclude-rules:
# Exclude some linters from running on tests files.
- path: _test\.go
linters:
- dupl
- gocyclo
- unused
# Exclude known linters from partially hard-vendored code,
# which is impossible to exclude via "nolint" comments.
- path: internal/hmac/
text: "weak cryptographic primitive"
linters:
- gosec
# Exclude some staticcheck messages
- linters:
- staticcheck
# TODO: Remove this exclude rules once we've migrated from
# controller-runtime fake client to envtest
text: "SA1019:" # deprecate warning
# Independently from option `exclude` we use default exclude patterns,
# it can be disabled by this option. To list all
# excluded by default patterns execute `golangci-lint run --help`.
# Default value for this option is true.
exclude-use-default: false
# Maximum issues count per one linter. Set to 0 to disable. Default is 50.
max-issues-per-linter: 0
# Maximum count of issues with the same text. Set to 0 to disable. Default is 3.
max-same-issues: 0
exclude-files:
- ".*\\.pb\\.go$"
- "^mock_.*\\.go$"
exclude-dirs:
- tools/
- scripts/
- idl/Go version
1.23
Code example or link to a public repository
not a public repositoryldez commented
Hello,
without a reproducible example, it's impossible to diagnose.
So, please, provide a reproducible example: the information of the full workflow, the go.mod, the exact local Go version, etc.
timtoronto634 commented
Hi, thank you for the development and maintainance!
we are also experiencing the performance degradation after bumping from v1.57 to v1.61
here are the information.
entire worflow file
name: Validate
on:
push:
permissions:
contents: read
jobs:
golangci-lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
with:
go-version: "1.23.2"
- name: golangci-lint
uses: golangci/golangci-lint-action@v6
with:
version: v1.61.0
Golangci-lint configuration
run:
go: 1.23.2
timeout: 5m
modules-download-mode: readonly
build-tags:
- test
linters-settings:
revive:
rules:
- name: line-length-limit
arguments: [100]
- name: comment-spacings
arguments: []
- name: datarace
- name: early-return
arguments: []
- name: exported
- name: optimize-operands-order
- name: package-comments
- name: time-equal
- name: unreachable-code
stylecheck:
checks: ["all", "-ST1003"]
sloglint:
key-naming-case: camel
linters:
enable:
- revive
- stylecheck
- sloglint
issues:
exclude-rules:
- linters:
- revive
source: "^// https://github.com/"
- linters:
- staticcheck
text: "SA3000"
exclude-dirs:
- gen/
Go version
1.23.2
Hope this helps, and thanks in advance.
shiyuhang0 commented
Thanks. It runs well after the first slow execution, maybe there are too many codes to check in the first execution when upgrade