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
pull-kubernetes-verify-govet-levee fails everything now #111452
Comments
@MikeSpreitzer: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/priority critical-urgent |
Looks like it's due to golang/go#48525. Edit: but this should have affected 1.18 too, not sure why it only fails on 1.19 yet. |
Why the tests didn't fail in #111254:
|
For future - @palnabarun, can we document this, where we need to wait for the image bump to propagate to the CI so that changes such as #111254 can test on that? |
Also, looks like adding support for type parameters in |
Not sure what happened in go1.19 that is causing the panic, the go issue linked by @nikhita effects go1.18 as well |
go 1.19 is the first release to use generics in the standard library though - https://pkg.go.dev/sync/atomic@go1.19rc2#Pointer 🤔 |
Let's open an issue in the go repo? If this is due to generics in the std lib, I'd expect the go team to prioritize fixing it. |
I can create one, worst case we'll understand a little more about Go! |
Created: golang/go#54086 |
Trying to think of how to unblock the CI for now: So far:
I can think of 2 ways to unblock the CI for now:
Also, as per golang/go#48525, further work on this is moved to the go1.20 release, unless we are able to fix it in upstream Go as part of 1.19, waiting for 1.19 GA also wouldn't help I guess. |
This might be easier/better than disabling the govet-levee check completely and would help unblock master for now. We could also keep the job on go1.18 until the Go team fixes it. |
Created kubernetes/test-infra#26931 and kubernetes/test-infra#26932 to move the test back to go1.18 to unblock master for now (in case we want to go with option 2 above). |
Kicked off the job at #111449 (comment) after kubernetes/test-infra#26931 merged, the job is now green - https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/111449/pull-kubernetes-verify-govet-levee/1552238594398097408 |
NOTE: this is in a tool we use |
using an older go version here means a skew in the go parser, it's probably fine in this instance, but as a general rule we probably want linters / analysis tools on the same go version. How long do we expect to keep this out of sync? Do we have a path forward? |
@BenTheElder the forward path is folks responsible for |
I mean on our end it is only reasonable to “fix” by rolling back go for one job if we expect to be able to do so short term. it looks like we can hope for a fix soon golang/go#48525 (comment) |
I left a description of a fix on golang/go#54086 (comment). |
Thank you, @timothy-king! |
This prevents crashes on Go code containing generics. The standard library now contains generics at head and levee crashes for folks using newer toolchains. See kubernetes/kubernetes#111452.
* Update to dependency on golang.org/x/tools to v0.1.12. This prevents crashes on Go code containing generics. The standard library now contains generics at head and levee crashes for folks using newer toolchains. See kubernetes/kubernetes#111452. * Update GH workflow to use go 1.18.
back on its feet now. |
Which jobs are failing?
pull-kubernetes-verify-govet-levee
Which tests are failing?
verify: govet-levee
Since when has it been failing?
Failing everything from 7:35 PM EDT July 26.
Failing almost everything from 5:29 PM EDT July 26.
Testgrid link
https://k8s-testgrid.appspot.com/presubmits-kubernetes-blocking#pull-kubernetes-verify-govet-levee
Reason for failure (if possible)
No response
Anything else we need to know?
No response
Relevant SIG(s)
/sig testing
The text was updated successfully, but these errors were encountered: