Repository navigation
chore(deps): drop k8s.io/kubernetes and bump k8s modules to v0.37.2 - #1333
Conversation
|
Claude finished @mbevc1's task in 25s —— View job Follow-up review: commits be65f8b..6aaf4c4
What changed in this range: Status of previously raised findings: none are touched by these commits — New issues in the changed lines (be65f8b..6aaf4c4): 0. The diff is an unrelated, mechanical dependency bump merged in from main; nothing to flag. |
7001be1 to
f1fa5c7
Compare
Follow-up review: commits f1fa5c7..7d8a9fdStatus of previous findings:
New inline comments on the changed lines (f1fa5c7..7d8a9fd): 0 I reviewed the new All three previously raised findings are resolved and no new issues were found in the changed lines. |
k8s.io/kubernetes is at v1.37.2 but the replace block pinned every k8s.io staging module to v0.37.0, so the build mixed two patch releases. Dependabot only edits require lines, so its k8s bumps were silently overridden by the replace block.
k8s.io/kubernetes was imported for a single test helper, WaitForPodNameRunningInNamespace. Its go.mod requires the k8s.io staging modules at the unpublished v0.0.0, which forced a 32-line replace block and left `go list -m all` unresolvable (k8s.io/cri-streaming has no published version). The helper is replaced by a wait.PollUntilContextTimeout loop with the same semantics: 5 minute timeout, retry while the pod is missing, stop early on a terminal phase. This removes the replace block and 53 modules from the graph. The client-go require now states v0.37.2, the version the replace was already selecting.
waitForPodRunning retried every Get error, so a permanent failure such as a 403 polled for the full 5 minutes and surfaced only "context deadline exceeded". It now retries only not-found and transient errors (timeout, 429, 503) and returns anything else immediately, matching the e2e framework helper it replaced.
…for a pod A 504 server timeout, a connection reset or an unexpected EOF from the API server failed the wait on the first poll, so a single transient blip could fail the whole KubeTestSuite. These are now retried like the other transient errors. Also call CoreV1 through suite.clientset.Clientset, as the rest of the file does.
A timed-out wait returned a bare "context deadline exceeded", which does not say whether the pod was stuck in Pending (for example on an image pull) or the API kept returning transient errors. The error now includes the last observed phase and the last retried error. The timeout is detected by comparing against the deadline rather than with wait.Interrupted: when the final poll races the deadline, client-go's rate limiter fails the Get with an error that does not wrap context.DeadlineExceeded.
f2b6c19 to
be65f8b
Compare
Remove the
k8s.io/kubernetesdependency, which was only used by one test helper, and bump the k8s modules to v0.37.2. Its unpublishedv0.0.0requirements forced a 32-line replace block that Dependabot cannot update, so the staging modules had drifted to v0.37.0 behind kubernetes v1.37.2.Review notes
e2epod.WaitForPodNameRunningInNamespaceis replaced bywaitForPodRunningininternal/kube/kube_test.go, await.PollUntilContextTimeoutloop with the same semantics: 5 min timeout, retry not-found and transient API errors (timeout, 429, 503), stop early onSucceeded/Failed, fail fast on any other error.go.mod(ginkgo, prometheus, cel-go, kustomize, otel exporters, …). No remaining module changes version; theclient-gorequire now states v0.37.2, which the replace already selected.go list -m allresolves again.Checklist
charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR