Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
Linters are failing--maybe we need to merge #6078 first? |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6161 +/- ##
=======================================
Coverage 44.43% 44.43%
=======================================
Files 280 280
Lines 25367 25367
=======================================
Hits 11272 11272
Misses 13283 13283
Partials 812 812 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@mboersma: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. |
| module sigs.k8s.io/cluster-api-provider-azure | ||
|
|
||
| go 1.24.6 | ||
| go 1.25.0 |
There was a problem hiding this comment.
Could we please hold off bumping this until a CAPZ release with CAPI 1.12 is out?
CAPI 1.12 is matched with Go 1.24: https://github.com/kubernetes-sigs/cluster-api/blob/1a1852c74072febc3fbf9823c9dd32f4cd6cc747/go.mod#L3
There was a problem hiding this comment.
Maybe CAPI just forgot to do that. k/k has been using 1.25 since long ago. If we don't want to keep aligned with k/k, at lease can we set gotoolchain=auto to unblock the builds?
kubernetes-sigs/cloud-provider-azure#9930
There was a problem hiding this comment.
I don't think core CAPI forgot to do that.
My understanding is that Core CAPI matches a specific k/k version in go.mod.
In the case of CAPI 1.12 it matches k/k 0.34 libs and, go 1.24 as that's what k/k 1.34 is based off of https://github.com/kubernetes/kubernetes/blob/ebfac057369b21558006b8815821ab2fb1e29f2d/go.mod#L9
When CAPI 1.13 will be out, it'll will be based off of k/k 0.35 libs (which use go 1.25) so the overall go directive will become 1.25 (you can already see this in CAPI main here and here).
Hence given:
CAPZ 1.22.z (already released) is based off:
I am expecting CAPZ 1.23.0 will be based off of:
- CAPI 1.12 (already like so in CAPZ main)
- k/k 0.34 libs (already like so in CAPZ main)
- and Go 1.24 (not 1.25. It already is like that in CAPZ main)
at lease can we set gotoolchain=auto to unblock the builds?
Better to check with @mboersma about this. Downstream we use gotoolchain=local for reproducible builds, not sure if there are such constraints here.
There was a problem hiding this comment.
/hold
Yes, we try to stick with the Go compiler used for the version of CAPI we have vendored into CAPZ. Sometimes that means we lag far behind the current Go release and we get tagged for CVEs that are only fixed in the current Go toolchain.
But let's hold off on this until we release CAPZ 1.23, which should be any day now.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Updates the Go toolchain to v1.25.8 and bumps golang.org/x/net and the Trivy scanner.
The weekly security scan GH action broke, because:
Which issue(s) this PR fixes:
See weekly security scan
Special notes for your reviewer:
While we try to stick with the Go toolchain used by the CAPI release we import, it should be safe to move forward here. CAPI's
mainbranch made these same changes.I verified locally that CAPZ has a clean bill of health after this:
TODOs:
Release note: