Using Go Install to Install golangci-lint in Container

[jon-whit]

I'm using the tools.go pattern to install dependencies for my Go project. This happens for both local development and within the CI/CD environment (trying to make it consistent across the board).

Since I install my tools from tools.go, within a container when I try to go install golangci-lint I experience some build issues. Here are some examples of what I'm experiencing:

➜ docker run --rm -it golang:1.17-alpine sh
/go/src # go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
...
# github.com/golangci/golangci-lint/cmd/golangci-lint
/usr/local/go/pkg/tool/linux_arm64/link: running gcc failed: exec: "gcc": executable file not found in $PATH

If I add gcc and try again it leads to another error:

➜ docker run --rm -it golang:1.17-alpine sh
/go/src # apk add gcc
/go/src # go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
...
/go/src # go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
# github.com/golangci/golangci-lint/cmd/golangci-lint
/usr/local/go/pkg/tool/linux_arm64/link: running gcc failed: exit status 1
collect2: fatal error: cannot find 'ld'
compilation terminated.

What do I misunderstand about golangci-lint? I'm not sure I understand why it depends on gcc standard glibc libraries etc.. Could someone help me achieve what I'm trying to do?

[ldez]

First, I would like to discourage you from using the tools.go pattern because:

• if your project uses the same library as golangci-lint, you can influence your project or golangci-lint.
• your project and golangci-lint can use different versions of Go to build. Currently, golangci-lint uses go1.18

  golangci-lint/go.mod

  Line 3 in 10f50c3

  go 1.18

golangci-lint doesn't depend on GCC, you have to do that:

CGO_ENABLED=0 go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest

[jon-whit]

@ldez CGO_ENABLED=0 fixed it 👍 .

I'd like to understand this comment better though.

if your project uses the same library as golangci-lint, you can influence your project or golangci-lint.

This isn't necessarily true if you structure your tooling properly, right? For example I have a project structure like so:

project/
  main.go
  tools/
    go.mod // github.com/jon-whit/project/tools
    go.sum
    tools.go
  go.mod // github.com/jon-whit/project
  go.sum

The module dependencies will be managed independently from one another, but you'll still be able to script the tool management in an easy way. For example, with a Makefile you could have

.PHONY: download
gotidy:
    cd tools && go mod tidy

.PHONY: install-tools
install-tools: gotidy
    cd tools && go list -f '{{range .Imports}}{{.}} {{end}}' tools.go | CGO_ENABLED=0 xargs go install -mod=readonly

This way the top-level project's go.mod won't track dependencies (transitive or direct) from the golangci-lint dependency, because it's a tooling dep defined in it's own tooling Go module.

your project and golangci-lint can use different versions of Go to build. Currently, golangci-lint uses go1.18

I'm not sure I understand why the version of Go that golangci-lint is built against influences it's behavior linting source code authored with a different target version of Go in my project. I could understand how different built versions of golangci-lint could have different behavior, but shouldn't the linting rules for golangci-lint apply uniformly regardless of the target language my project is built in? If I'm building against Go 1.18 there will obviously be more specific rules (generics etc..), but for any given version of Go that my project chooses to use, why does that have any relationship with the version of Go that golangci-lint is built against? I'm not sure I understand your point. Could you please elaborate?

[ldez]

This isn't necessarily true if you structure your tooling properly, right?

yes but the tools.go pattern in the article you linked doesn't show that. My answer is in the context you provide.

linting rules for golangci-lint apply uniformly regardless of the target language my project is built in

golangci-lint is a wrapper around linters, we don't control the behavior of linters themself.

Currently, we don't use for example strings.Cut but if we do that the tools.go pattern will fail because you will use go1.17.

We have to use the latest version of Go to be able to handle new elements of the language, so we can use those elements and the linters too.