Can't run linter goanalysis_metalinter 1.24.x: failed prerequisites #995
Comments
|
linter began failing suddenly a short while ago, just upgraded (brew) from 1.23.2 -> 1.23.8, working again. considering description above, i suspect it was re-broken :P |
|
this issue is about the new 1.24.x versions |
|
Having the same issue with a slight random effect: We do have a repo containing several
That "random" has following effect:
Between those executions no code chance was made, all executions were made in a fresh container from the same image… |
|
golangci-lint has version 1.24.0 built from 6fd4383 on 2020-03-15T11:30:52Z Config |
|
Also seeing this same issue and it seems very erratic/intermittent. You should be able to reproduce it with: https://github.com/authelia/authelia with the following configuration: Config |
3 tasks
|
I am also encountering this issue. What is weird is that I cannot reproduce it locally on my machine. The bug only triggers on my CI (Gitlab). Running Go 1.14 and golangci-lint 1.24.0 both locally and in the CI. Go code compiles successfully, and all unit tests succeed, so there are no compile errors present in the code. And like other people have commented, the "failed prerequisites" error isnt always consistent. It fails on different parts of the code for whatever reason. #827 is the original closed issue that OP referenced. |
|
I encountered the same issue after updating golangci-lint 1.23.8->1.24.0 and Golang 1.14.1->1.14.2. We are running multiple golangci-lint instances in docker containers in parallel. Removing the volume mount for the golangci-lint cache directory fixed the issue. |
Cannot confirm. We're running builds within a Docker container without volume mounts and the first build always produces errors while a second (sequential) build in the same container does no longer produce those errors. There is no concurrency involved on our side when experiencing this. |
|
For those who can't reproduce this issue locally: please try cleaning golangci cache before running. $ golangci-lint cache clean |
|
@ernado cleaning the cache does not help to reproduce the issue locally with version 1.24.0 for me |
|
Please do |
|
@ernado I can not reproduce the error locally neither with 1.24.0 nor with 1.25.0, |
|
@fho the |
|
I fixed the problem with: |
|
Closing this for now. Please open new issue if problem will reappear, but ensure that you are installing golangci-lint either via binary or via go modules. Thanks everyone. |
jirfag
added a commit
that referenced
this issue
May 3, 2020
The primary improvement is in early clearing of
analyzed package's TypeInfo, facts, etc for
whole program analyzers (`unused`). Clear it when it
becomes unused and GC collects them early. Initially this
clearing was performed for all analyzers except `unused`.
Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4
Also in this commit:
* speed up loading packages from export data (2.5s -> 2.1s for std)
by not using mutex for export data since it was allowed in
x/tools#07722704da13
* make an order of execution of linters stable
* update renameio and robustio
* use robustio in caching
Relates: #987, #994, #995, #1011
jirfag
added a commit
that referenced
this issue
May 3, 2020
The primary improvement is in early clearing of
analyzed package's TypeInfo, facts, etc for
whole program analyzers (`unused`). Clear it when it
becomes unused and GC collects them early. Initially this
clearing was performed for all analyzers except `unused`.
Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4
Also in this commit:
* speed up loading packages from export data (2.5s -> 2.1s for std)
by not using mutex for export data since it was allowed in
x/tools#07722704da13
* make an order of execution of linters stable
* update renameio and robustio
* use robustio in caching
Relates: #987, #994, #995, #1011
jirfag
added a commit
that referenced
this issue
May 3, 2020
The primary improvement is in early clearing of
analyzed package's TypeInfo, facts, etc for
whole program analyzers (`unused`). Clear it when it
becomes unused and GC collects them early. Initially this
clearing was performed for all analyzers except `unused`.
Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4
Also in this commit:
* speed up loading packages from export data (2.5s -> 2.1s for std)
by not using mutex for export data since it was allowed in
x/tools#07722704da13
* make an order of execution of linters stable
* update renameio and robustio
* use robustio in caching
Relates: #987, #994, #995, #1011
jirfag
added a commit
that referenced
this issue
May 5, 2020
The primary improvement is in early clearing of
analyzed package's TypeInfo, facts, etc for
whole program analyzers (`unused`). Clear it when it
becomes unused and GC collects them early. Initially this
clearing was performed for all analyzers except `unused`.
Update staticcheck from v0.0.1-2019.2.3 to v0.0.1-2020.1.4
Also in this commit:
* speed up loading packages from export data (2.5s -> 2.1s for std)
by not using mutex for export data since it was allowed in
x/tools#07722704da13
* make an order of execution of linters stable
* update renameio and robustio
* use robustio in caching
Relates: #987, #994, #995, #1011
|
Is this issue reoccurring in version 1.31.0 on Windows 10? It works on MacOS, but Windows still appears to be borked. |
|
I'm running version 1.31.0 on MacOS with Go 1.15, having this issue |
|
I was able to get around this issue on macOS Catalina (10.15.6) My issue was the installation was taking a previously installed version and not the new home-brew install. I found something was fishy by checking the version I uninstalled the brew version: did a find on my root file system for any rm any golangci-lint binaries in your go paths reinstalled golangci Verify Version Now I can run linter without any issues |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I still have the same issue (but you guys closed it, which you shouldn't, because it is not fixed)
Using the new 1.24.0 with Go 1.14
Config file
Go environment
Verbose output of running
It's always on the same part. What is interesting about it, that it complains about a struct and a function not being present. They are present within the package, only not in that file.
The software compiles, so there's nothing wrong, only the linter sees that differently. :-(
The text was updated successfully, but these errors were encountered: