Skip to content
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.

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

Required access since v1.44.0 ist undocumented #2523

Closed
4 tasks done
bosix opened this issue Jan 26, 2022 · 9 comments
Closed
4 tasks done

Required access since v1.44.0 ist undocumented #2523

bosix opened this issue Jan 26, 2022 · 9 comments
Labels
question Further information is requested

Comments

@bosix
Copy link
Contributor

bosix commented Jan 26, 2022

Welcome

  • Yes, I'm using a binary release within 2 latest major releases. Only such installations are supported.
  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, I've included all information below (version, config, etc).
  • Yes, I've tried with the standalone linter if available. (https://golangci-lint.run/usage/linters/)

Description of the problem

I've updated golangci-lint from v1.43.0 to v1.44.0. Since then I get an error when running the tool inside an environment which does not have full access to all 3rd party libraries from go.mod. This can happen when private libraries are used inside the go project.

The error disappears when I completely setup the environment including a setup of GOPRIVATE and proper access to the secured libraries (I use git for this purpose) but I think it should be mentioned anywhere in the docs that since v1.44.0 golangci-lint needs access to all libraries from go.mod.

Version of golangci-lint

Used docker image: golangci/golangci-lint:v1.44.0-alpine@sha256:8ac9a08a9e2f627cdc2dcae7255308ca63aa56f3015bb9d3d650692b1c52c768

Configuration file

$ cat .golangci.yml
output:
    sort-results: true

linters:
    disable-all: true
    #    https://golangci-lint.run/usage/linters/
    enable:
        - asciicheck    # check for non-ascii chars in identifiers (vars, functions, types, ...)
        - bodyclose # check for unclosed bodies of http requests (does not work in very complex scenarios)
        - deadcode  # check unused code
        - dupl  # check for duplicates with at least 100 chars (can be changed via config)
        - durationcheck # check for 2 durations which are multiplied by accident
        - errcheck  # check that all errors are handled
        - exportloopref # check for exported pointers on loop variables
        - funlen #check for too long functions (default: 60 lines or 40 statements)
        - gocognit  # check for functions with too high cognitive complexity
        - goconst   # check for multiple used strings with could be replaced by a const
        - godox # check for todos and fixmes
        - gofumpt   # check against the coding standard rules of https://github.com/mvdan/gofumpt (an extension of gofmt)
        - gomnd # check magic numbers
        - gosimple  # check if code can be simplified e.g. !condition instead of condition == false
        - govet     # check incorrect printf format-argument calls
        - ifshort   # check for if-statements which can be replaced by short version
        - ineffassign   # check unused assignments to existing vars
        - lll   # check max line length
        - nilerr    # check if function returns nil although a checked error is not nil
        - paralleltest # check if t.Parallel() is used in all tests
        - predeclared # check that definitions (vars, functions, ...) do not use predeclared names like int, string, copy, print, ...
        - revive    # linter (replaces golint)
        - unconvert # check unnecessary type conversions
        - unparam   # check (well... it tries) to find unused func params or returns
        - unused    # check unused constants, functions, types, vars and struct fields

linters-settings:
    gocognit:
        min-complexity: 15

issues:
    exclude-rules:
        -   path: _test\.go
            linters:
                - funlen
                - errcheck
                - dupl
                - goconst
                - bodyclose
                - lll
    fix: true

Go environment

(this is the working environment)

$ go version && go env
go version go1.17.6 linux/amd64
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bosi/.cache/go-build"
GOENV="/home/bosi/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/bosi/go/pkg/mod"
GONOPROXY="gitlab.com/softwarepinguin/*"
GONOSUMDB="gitlab.com/softwarepinguin/*"
GOOS="linux"
GOPATH="/home/bosi/go"
GOPRIVATE="gitlab.com/softwarepinguin/*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.17"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.17/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build518308105=/tmp/go-build -gno-record-gcc-switches"

Verbose output of running

$ golangci-lint run ./...
level=warning msg="[runner] Can't run linter goanalysis_metalinter: buildir: failed to load package : could not load export data: no export data for \"gitlab.com/softwarepinguin/rapi\""
level=error msg="Running error: 1 error occurred:\n\t* can't run linter goanalysis_metalinter: buildir: failed to load package : could not load export data: no export data for \"gitlab.com/softwarepinguin/rapi\"\n\n"

Code example or link to a public repository

You just need a go project which uses a private library. I can reproduce the issue easily inside a ci/cd pipeline where the complete environment is empty.
cd pipeline
@bosix bosix added the bug Something isn't working label Jan 26, 2022
@boring-cyborg
Copy link

boring-cyborg bot commented Jan 26, 2022

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

@ldez
Copy link
Member

ldez commented Jan 26, 2022

Hello,

We have not changed something related to that, the only thing that can produce that is a change inside Go or the official Go tooling.

Can you retry with golangci-lint v1.43?

@ldez ldez added the feedback required Requires additional feedback label Jan 26, 2022
@bosix
Copy link
Contributor Author

bosix commented Jan 26, 2022

Hi @ldez,

I've used golangci/golangci-lint:v1.43.0-alpine@sha256:24d773a07983d19963b6e07c7d5bce1b7835f8fb37486d34081e6a40302c17c5 before and the warning was the same but the linter itself worked. The error message that cancels the execution of the linter is new. I use the renovate bot for such updates, so nothing has changed except the golangci-lint update.

@ldez
Copy link
Member

ldez commented Jan 26, 2022

I see the problem, you must disable at least gosimple and unused.

@ldez ldez added question Further information is requested and removed bug Something isn't working feedback required Requires additional feedback labels Jan 26, 2022
@bosix
Copy link
Contributor Author

bosix commented Jan 26, 2022

Ok, so it's more of a change in these linters than in golangci-lint. As I said, I already solved the problem by changing the environment settings. You can close this issue if you think it has nothing to do with golangci-lint. I just found it strange that the tool shows me errors even though 1 minor release before everything was fine.

@ldez
Copy link
Member

ldez commented Jan 26, 2022

You are using one or more linters that failed, previously we "silently" failed.
Since v1.44.0, when a linter failed we return the appropriate exit code.

In your case the problem is with buildir, this analyzer is a part of the staticcheck stack (staticcheck, gosimple, stylecheck and unused).

@bosix
Copy link
Contributor Author

bosix commented Jan 26, 2022

Do you mean "silently failed" like it does not tell me that the linter does not work at all?

@ldez
Copy link
Member

ldez commented Jan 26, 2022

Before when a linter failed (a real failure not just linter reports), golangci-lint just displayed a warning.
But it's was a problem because if you don't take care of your logs, multiple linters can be skipped, because the exit code was 0.

The related PR #2471

Your problem is not related to staticcheck itself or golangci-lint, but to the fact that you ignored the important warning.
But as the warning was a "silent" warning, it's understanable.

@bosix
Copy link
Contributor Author

bosix commented Jan 26, 2022

Thank you for the explanation :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants