Skip to content

CI: golangci is broken with go canary (1.24RC) #3761

Closed

Description

@apostasie

Description

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.

This can be reproduced locally on a laptop:

  • install go 1.24RC
  • download binary curl -sSfLO https://github.com/golangci/golangci-lint/releases/download/v1.62.2/golangci-lint-1.62.2-darwin-arm64.tar.gz

Then:

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)

None

Host information

No response

Activity

  1. changed the title [-]golangci is broken with go canary (1.24RC)[/-] [+]CI: golangci is broken with go canary (1.24RC)[/+] on Dec 13, 2024
  2. apostasie commented on Dec 13, 2024

    @apostasie
    ContributorAuthor

    Added notes:

    • golangci DOES compile just fine against golang 1.24
    • using the action to go install is a no-go, as you cannot separate GOOS for install and runtime phases... :/

    The action install mechanism does not provide much value.

    Suggesting we just drop that part and install normally.

  3. apostasie commented on Mar 5, 2025

    @apostasie
    ContributorAuthor

    @AkihiroSuda can you assign this to me?

    I will fix it as part of the current CI series.

  4. added
    bugSomething isn't working
    area/cie.g., CI failure
    and removed on Mar 5, 2025
  5. fahedouch commented on Mar 11, 2025

    @fahedouch
    Member
  6. fahedouch commented on Mar 11, 2025

    @fahedouch
    Member

    https://github.com/containerd/project-checks can host a home compiled linter too

  7. apostasie commented on Mar 12, 2025

    @apostasie
    ContributorAuthor

    what gives the benchmark of https://github.com/golangci/golangci-lint/blob/v1.64.6/go.mod (go1.23) ?

    Did not get that. What do you mean?

  8. apostasie commented on Mar 12, 2025

    @apostasie
    ContributorAuthor

    https://github.com/containerd/project-checks can host a home compiled linter too

    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.

  9. fahedouch commented on Mar 12, 2025

    @fahedouch
    Member

    https://github.com/containerd/project-checks can host a home compiled linter too

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area/cie.g., CI failurebugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions