Bump k8s.io/apimachinery from 0.34.3 to 0.35.0#62
Conversation
dependabot
Bot
added
dependencies
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dependabot[bot] The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @dependabot[bot]. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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-sigs/prow repository. |
Bumps [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery) from 0.34.3 to 0.35.0. - [Commits](kubernetes/apimachinery@v0.34.3...v0.35.0) --- updated-dependencies: - dependency-name: k8s.io/apimachinery dependency-version: 0.35.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/go_modules/k8s.io/apimachinery-0.35.0
branch
from
2d1bc78 to
8cecf62
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
📝 WalkthroughWalkthroughUpdated Go toolchain version from 1.24.6 to 1.25.0 in Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@go.mod`:
- Line 3: The pipeline is failing because go.mod specifies "go 1.25.0" but CI
uses Go 1.24.11; either update the CI toolchain to a Go version that supports
1.25.0 or change the go.mod version to match the CI (e.g., lower "go 1.25.0" to
"go 1.24" or the exact 1.24.11 used), then re-run the build; locate and edit the
go.mod entry "go 1.25.0" to make the versions consistent with your CI
environment.
- Line 89: Update the indirect gRPC dependency to a patched version by either
adding a direct require for google.golang.org/grpc at v1.79.3 (or later) in
go.mod or by bumping the direct modules that pull it in (e.g., k8s.io/client-go
or sigs.k8s.io/controller-runtime) to versions that themselves require
google.golang.org/grpc >= v1.79.3; after changing go.mod run go get
google.golang.org/grpc@v1.79.3 (or bump the client-go/controller-runtime version
and run go mod tidy) and verify with go list -m all that google.golang.org/grpc
is now >= v1.79.3, then run tests and go vet to ensure no regressions.
- Around line 11-12: The go.mod currently pins k8s.io/apimachinery to v0.35.0
while k8s.io/client-go is v0.34.2, causing an unsupported staging-module version
mismatch; either downgrade k8s.io/apimachinery to v0.34.2 to match client-go
v0.34.2, or upgrade k8s.io/client-go (and all related staging modules such as
k8s.io/api, k8s.io/apiextensions-apiserver, k8s.io/apiserver,
k8s.io/component-base) to v0.35.x so all k8s modules are on the same minor
version—update the module versions in go.mod accordingly and run go mod tidy to
refresh the lock.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 831c1df6-1242-48fe-a101-384be768ce6b
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (1)
go.mod
| module github.com/openstack-lightspeed/operator | ||
|
|
||
| go 1.24.6 | ||
| go 1.25.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the latest stable Go release and check if 1.25.0 exists
curl -s https://go.dev/dl/?mode=json | jq -r '.[].version' | head -10Repository: openstack-lightspeed/operator
Length of output: 90
🌐 Web query:
What is the latest stable release of Go? Has Go 1.25.0 been released?
💡 Result:
- Latest stable Go release: Go 1.26.1 (released 2026-03-05). [1]
- Has Go 1.25.0 been released? Yes. Go 1.25 was officially released (and 1.25.0 is part of that release series). [2]
Sources:
[1] Go “Release History” page (lists go1.26.1 release date) (go.dev)
[2] Go blog announcement “Go 1.25 is released” (go.dev)
Citations:
- 1: https://go.dev/doc/devel/release?utm_source=openai
- 2: https://go.dev/blog/go1.25?utm_source=openai
Update Go toolchain version or CI environment: pipeline failure due to version mismatch.
The CI pipeline is failing because go.mod requires Go 1.25.0, but the build environment is using Go 1.24.11. Go 1.25.0 is a valid released version, so the issue is that the CI environment needs to be updated to support it, or the go.mod requirement needs to be lowered to match the available toolchain.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` at line 3, The pipeline is failing because go.mod specifies "go
1.25.0" but CI uses Go 1.24.11; either update the CI toolchain to a Go version
that supports 1.25.0 or change the go.mod version to match the CI (e.g., lower
"go 1.25.0" to "go 1.24" or the exact 1.24.11 used), then re-run the build;
locate and edit the go.mod entry "go 1.25.0" to make the versions consistent
with your CI environment.
| k8s.io/apimachinery v0.35.0 | ||
| k8s.io/client-go v0.34.2 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check all k8s.io dependencies and their versions
rg -n "k8s\.io/" go.mod | sortRepository: openstack-lightspeed/operator
Length of output: 813
🌐 Web query:
Is k8s.io/apimachinery v0.35.0 compatible with k8s.io/client-go v0.34.2? What is the Kubernetes version compatibility matrix for these packages?
💡 Result:
No—it’s not a supported/expected combination to use k8s.io/apimachinery v0.35.0 with k8s.io/client-go v0.34.2. client-go v0.34.2 is published together with—and in practice expects—the matching staging libs at the same minor/patch (its go.mod requires k8s.io/apimachinery v0.34.2).[2] Also, apimachinery explicitly states it provides no compatibility guarantees and is meant to track Kubernetes/staging in lockstep.[3]
What versions should match?
Kubernetes tags its staging Go modules so that Kubernetes v1.x.y corresponds to k8s.io/* v0.x.y (same x.y, major stays 0).[1]
Kubernetes version compatibility matrix (client-go ↔ Kubernetes)
From the client-go README compatibility matrix (rows are the client-go tag; columns are the Kubernetes cluster version):[1]
| client-go tag | Kubernetes cluster versions shown in matrix |
|---|---|
v0.29.0 |
1.29–1.34 (see upstream matrix for ✓/+/− details) |
v0.30.0 |
1.29–1.34 |
v0.31.0 |
1.29–1.34 |
v0.32.0 |
1.29–1.34 |
v0.33.0 |
1.29–1.34 |
v0.34.0 |
1.29–1.34 |
So:
client-go v0.34.x↔ Kubernetesv1.34.x[1]apimachinery v0.35.0↔ Kubernetesv1.35.0(by the same tagging rule:v1.x.y→v0.x.y).[1]
Practical guidance
- If you need client-go
v0.34.2, use apimachineryv0.34.2(andk8s.io/api v0.34.2).[2] - If you want apimachinery
v0.35.0, bump client-go tov0.35.xas well.
Sources: Kubernetes client-go versioning + compatibility matrix[1], client-go v0.34.2 go.mod dependency on apimachinery v0.34.2[2], apimachinery compatibility statement[3].
Critical: Unsupported Kubernetes dependency version mismatch.
k8s.io/apimachinery v0.35.0 is incompatible with k8s.io/client-go v0.34.2. The client-go package at v0.34.2 is published with and explicitly requires apimachinery v0.34.2. Kubernetes staging modules must remain synchronized across minor/patch versions and provide no cross-version compatibility guarantees.
Both client-go v0.34.x and apimachinery v0.34.2 are aligned for Kubernetes v1.34.x. Using apimachinery v0.35.0 (which targets Kubernetes v1.35.0) will cause runtime failures with client-go v0.34.2.
Fix: Either upgrade k8s.io/client-go and related packages (k8s.io/api, k8s.io/apiextensions-apiserver, k8s.io/apiserver, k8s.io/component-base) to v0.35.x, or revert k8s.io/apimachinery to v0.34.2.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` around lines 11 - 12, The go.mod currently pins k8s.io/apimachinery
to v0.35.0 while k8s.io/client-go is v0.34.2, causing an unsupported
staging-module version mismatch; either downgrade k8s.io/apimachinery to v0.34.2
to match client-go v0.34.2, or upgrade k8s.io/client-go (and all related staging
modules such as k8s.io/api, k8s.io/apiextensions-apiserver, k8s.io/apiserver,
k8s.io/component-base) to v0.35.x so all k8s modules are on the same minor
version—update the module versions in go.mod accordingly and run go mod tidy to
refresh the lock.
| gomodules.xyz/jsonpatch/v2 v2.4.0 // indirect | ||
| google.golang.org/genproto/googleapis/api v0.0.0-20250603155806-513f23925822 // indirect | ||
| google.golang.org/genproto/googleapis/rpc v0.0.0-20250603155806-513f23925822 // indirect | ||
| google.golang.org/grpc v1.73.0 // indirect |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for security advisories for grpc-go
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: GO, package: "google.golang.org/grpc") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: openstack-lightspeed/operator
Length of output: 233
🌐 Web query:
What is the patched version for GHSA-p77j-4mvh-x3m3 affecting google.golang.org/grpc v1.73.0? Which direct dependency needs to be updated to resolve this?
💡 Result:
- Patched version (for
google.golang.org/grpc): v1.79.3 (the advisory says affected versions are < 1.79.3). [1] - Direct dependency to update to resolve it: update your project’s direct requirement on
google.golang.org/grpcto v1.79.3+ (i.e., ensure your rootgo.modpulls ingoogle.golang.org/grpc >= 1.79.3). [1]
Sources
[1] GitHub Advisory Database – GHSA-p77j-4mvh-x3m3 (CVE-2026-33186) GHSA-p77j-4mvh-x3m3
🏁 Script executed:
cd . && head -100 go.mod | tail -20Repository: openstack-lightspeed/operator
Length of output: 1058
🏁 Script executed:
rg "google.golang.org/grpc" go.mod -A 1 -B 1Repository: openstack-lightspeed/operator
Length of output: 254
🏁 Script executed:
rg "require \(" go.mod -A 50 | head -60Repository: openstack-lightspeed/operator
Length of output: 2956
🏁 Script executed:
# Check which direct dependency pulls in grpc by checking their go.mod files
# Let's look at the most likely candidates: k8s.io/client-go, sigs.k8s.io/controller-runtime
cd . && grep -E "k8s.io/client-go|sigs.k8s.io/controller-runtime|github.com/openstack-k8s-operators/lib-common" go.mod | grep "require ("Repository: openstack-lightspeed/operator
Length of output: 55
🏁 Script executed:
# Try to understand the dependency chain by checking the module graph info
# Since we can't run 'go mod graph' which might be slow, let's search for any mentions of how to resolve this
cat go.mod | tail -5Repository: openstack-lightspeed/operator
Length of output: 274
Update google.golang.org/grpc to v1.79.3 or later to patch critical authorization bypass vulnerability.
google.golang.org/grpc v1.73.0 is vulnerable to GHSA-p77j-4mvh-x3m3 (CVE-2026-33186), a critical authorization bypass via improper handling of :path headers. The patched version is v1.79.3. Since this is an indirect dependency, update the direct dependencies (most likely k8s.io/client-go or sigs.k8s.io/controller-runtime) to versions that require google.golang.org/grpc >= v1.79.3, or add it as a direct requirement.
🧰 Tools
🪛 OSV Scanner (2.3.3)
[CRITICAL] 89-89: google.golang.org/grpc 1.73.0: gRPC-Go has an authorization bypass via missing leading slash in :path
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` at line 89, Update the indirect gRPC dependency to a patched version
by either adding a direct require for google.golang.org/grpc at v1.79.3 (or
later) in go.mod or by bumping the direct modules that pull it in (e.g.,
k8s.io/client-go or sigs.k8s.io/controller-runtime) to versions that themselves
require google.golang.org/grpc >= v1.79.3; after changing go.mod run go get
google.golang.org/grpc@v1.79.3 (or bump the client-go/controller-runtime version
and run go mod tidy) and verify with go list -m all that google.golang.org/grpc
is now >= v1.79.3, then run tests and go vet to ensure no regressions.
|
/ok-to-test |
|
@dependabot[bot]: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
2 participants
Bumps k8s.io/apimachinery from 0.34.3 to 0.35.0.
Commits
72d71eaMerge remote-tracking branch 'origin/master' into release-1.35e2a2dbcBump golang.org/x/crypto to v0.45.02e9c228Merge pull request #135131 from Dev1622/sig-storage/mock-expand-flake-fixf274aacvendor: update vendor and license metadata after replacing BeTrue usage in cs...9445443Resolve lint restriction on BeTrue by introducing Succeed() with contextual e...52154f7Update vendored dependencies5a348c5KEP-5471: Extend tolerations operators (#134665)6f89492Merge pull request #133648 from richabanker/merged-discoveryc77dde2util/sort: Add MergePreservingRelativeOrder for topological sorting729c13dMerge pull request #134624 from yt2985/podcertificates-betaYou can trigger a rebase of this PR by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)Summary by CodeRabbit