You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: golangci is broken with go canary (1.24RC) #3761
The core of the issue is that golangci is unable to work properly with a go version that is higher than the one it has been built with, resulting in hogging memory / CPU.
dmp@Synchronicity:~/Projects/go/nerd/nerdctl$ go version
go version go1.24rc1 darwin/arm64
dmp@Synchronicity:~/Projects/go/nerd/nerdctl$ time GOOS=linux /Users/dmp/tmp/golangci-lint-1.62.2-darwin-arm64/golangci-lint run
^C^C
real 2m10.275s
user 5m25.968s
sys 3m23.894s
vs.
dmp@Synchronicity:~/Projects/go/nerd/nerdctl$ go version
go version go1.23.4 darwin/arm64
dmp@Synchronicity:~/Projects/go/nerd/nerdctl$ time GOOS=linux /Users/dmp/tmp/golangci-lint-1.62.2-darwin-arm64/golangci-lint run
real 0m27.558s
user 1m38.488s
sys 0m47.445s
I have no idea what kind of voodoo golangci is doing, but clearly their binary installs are not usable for our purpose.
Solutions are either: the golangci github action offers to build / install instead of downloading pre-built (and that would work with go1.24), or we figure out how to install manually and remove the action, or we stop linting for canary (would be sad...).
It is unclear to me ATM if there will be unforeseen issues with 1.24 wrt golangci - from a glimpse, it seems that it is just fine and maps are just sugar.
Steps to reproduce the issue
No response
Describe the results you received and expected
na
What version of nerdctl are you using?
main
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
I find project-checks problematic. It cannot run locally on a developper laptop (obviously), so, you have to implement the same checks in your makefile anyhow. Also, project-checks does not even pass its own checks - it also does not bother to check for other GOARCH, just linux - which entirely defeats the purpose of covering licenses properly. Also it does not pin its tools versions, making for a moving target, and uses broken dependencies (go-licenses pre-v2 is useless). Either way, unless I misunderstood something, I do not see how that could be useful in that case.
I find project-checks problematic. It cannot run locally on a developper laptop (obviously), so, you have to implement the same checks in your makefile anyhow. Also, project-checks does not even pass its own checks - it also does not bother to check for other GOARCH, just linux - which entirely defeats the purpose of covering licenses properly. Also it does not pin its tools versions, making for a moving target, and uses broken dependencies (go-licenses pre-v2 is useless). Either way, unless I misunderstood something, I do not see how that could be useful in that case.
I do not see how that could be useful in that case.
compile our own linter and put it in project-checks, call the action when needed
Activity
[-]golangci is broken with go canary (1.24RC)[/-][+]CI: golangci is broken with go canary (1.24RC)[/+]apostasie commentedon Dec 13, 2024
Added notes:
The action install mechanism does not provide much value.
Suggesting we just drop that part and install normally.
apostasie commentedon Mar 5, 2025
@AkihiroSuda can you assign this to me?
I will fix it as part of the current CI series.
fahedouch commentedon Mar 11, 2025
what gives the benchmark of https://github.com/golangci/golangci-lint/blob/v1.64.6/go.mod (go1.23) ?
fahedouch commentedon Mar 11, 2025
https://github.com/containerd/project-checks can host a home compiled linter too
apostasie commentedon Mar 12, 2025
Did not get that. What do you mean?
apostasie commentedon Mar 12, 2025
I find project-checks problematic. It cannot run locally on a developper laptop (obviously), so, you have to implement the same checks in your makefile anyhow. Also, project-checks does not even pass its own checks - it also does not bother to check for other GOARCH, just linux - which entirely defeats the purpose of covering licenses properly. Also it does not pin its tools versions, making for a moving target, and uses broken dependencies (go-licenses pre-v2 is useless). Either way, unless I misunderstood something, I do not see how that could be useful in that case.
fahedouch commentedon Mar 12, 2025
compile our own linter and put it in
project-checks, call the action when needed