You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(kyverno): let the reports hotfix lint gate move to Go 1.27 #5492
The patched Kyverno reports-controller image (ReportsWatchPlan.Dockerfile) runs golangci-lint over the whole pinned upstream Kyverno source. It cannot move to the golang 1.27 builder (platform#5483) because of that lint step:
golangci-lint v2.11.4 and v2.13.x cannot read Go 1.27.2 export data. Their golang.org/x/tools only reads pkgbits up to V4; v0.50.0 added V5.
golangci-lint v2.15.0 reads it, but reports 12 new findings in upstream Kyverno code that our patch does not touch: gofumpt formatting, govet inline suggestions, and an unused nolintlint directive. Run: Verify reports controller at 59c7f89 on platform#5483.
Decision needed
How should the hotfix's lint gate treat upstream code?
Lint only the files our patch changes. This keeps the gate meaningful for our own code.
Keep the builder on Go 1.26 until we rebase onto a Kyverno release that is clean under the new linter.
Fix the findings inside our patch. This grows the patch we carry against upstream.
Disabling or relaxing linters is not an option.
Acceptance criteria
Verify reports controller passes on a golang 1.27 builder, or platform#5483 is closed with the chosen reason.
The lint step still fails on a real finding in the code our patch changes.
Decision (ours to make): option 1. The gate exists to catch defects in our watch-plan patch, not to restyle upstream Kyverno. Lint only the packages the patch changes, and keep the full-source go test step as it is. Next: implement this on platform#5483 and show the gate still fails on a finding planted in a patched file.
Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.
Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your .coderabbit.yaml:
issue_enrichment:
auto_enrich:
enabled: false
💬 Have feedback or questions? Drop into our discord!
Implementing the 10-28 decision, with one change to its scope. Linting only the patched package is not enough: 2 of the 12 findings are in pkg/controllers/report/resource/controller.go, on upstream lines the patch does not touch. So platform#5483 now limits the gate to the lines the patch changes, within that package.
Checked locally, on the pinned Kyverno source with the patch applied and golangci-lint v2.15.0, built with Go 1.27.3 rather than the 1.27.2 builder:
The tree matches the pinned patched source hash, and the gate reports 0 findings. The same package without the patch filter reports those 2 findings.
A wrong fmt.Errorf argument planted in watch_kinds.go fails the gate. So does a formatting fault on a line the patch adds there, and one on a line it changes in controller.go.
Limit: a line outside the patch is not linted, including a finding that a patched line causes elsewhere. The full go test step is unchanged, and go vet only runs here through the linter. CI on the PR is the check on the real builder.
Consolidating the earlier reader-compatibility report #5484 here. Both track the same Go 1.27 reports-controller upgrade in #5483. #5484 captured the original v2.11.4 export-data failure; this issue records the later v2.15.0 trial and its remaining findings, so maintaining two parallel upgrade plans would duplicate the same work.
Retained closure criteria: preserve the original failing native job and before/after evidence; record the relevant upstream release review; complete the real lint, test and build stages on the actual selected pinned builder; preserve failure on genuine findings; then complete current-head CI, substantive review, protected merge, default-branch verification and revalidation of #5483. The existing local-versus-native builder difference and line-filter limitation remain explicit and unresolved by this consolidation. This note approves no change to enforcement or lint scope.
#5492 remains the open owner for the decision and delivery. #5490 separately retains the required-check and merge-queue enforcement defect.
Activity
devantler commentedon Oct 28, 2026
Decision (ours to make): option 1. The gate exists to catch defects in our watch-plan patch, not to restyle upstream Kyverno. Lint only the packages the patch changes, and keep the full-source
go teststep as it is. Next: implement this on platform#5483 and show the gate still fails on a finding planted in a patched file.coderabbitai commentedon Oct 28, 2026
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
devantler commentedon Nov 1, 2026
Implementing the 10-28 decision, with one change to its scope. Linting only the patched package is not enough: 2 of the 12 findings are in
pkg/controllers/report/resource/controller.go, on upstream lines the patch does not touch. So platform#5483 now limits the gate to the lines the patch changes, within that package.Checked locally, on the pinned Kyverno source with the patch applied and golangci-lint v2.15.0, built with Go 1.27.3 rather than the 1.27.2 builder:
fmt.Errorfargument planted inwatch_kinds.gofails the gate. So does a formatting fault on a line the patch adds there, and one on a line it changes incontroller.go.Limit: a line outside the patch is not linted, including a finding that a patched line causes elsewhere. The full
go teststep is unchanged, andgo vetonly runs here through the linter. CI on the PR is the check on the real builder.devantler commentedon Nov 2, 2026
Consolidating the earlier reader-compatibility report #5484 here. Both track the same Go 1.27 reports-controller upgrade in #5483. #5484 captured the original v2.11.4 export-data failure; this issue records the later v2.15.0 trial and its remaining findings, so maintaining two parallel upgrade plans would duplicate the same work.
Retained closure criteria: preserve the original failing native job and before/after evidence; record the relevant upstream release review; complete the real lint, test and build stages on the actual selected pinned builder; preserve failure on genuine findings; then complete current-head CI, substantive review, protected merge, default-branch verification and revalidation of #5483. The existing local-versus-native builder difference and line-filter limitation remain explicit and unresolved by this consolidation. This note approves no change to enforcement or lint scope.
#5492 remains the open owner for the decision and delivery. #5490 separately retains the required-check and merge-queue enforcement defect.