Skip to content

fix(kyverno): let the reports hotfix lint gate move to Go 1.27 #5492

Open

Description

@devantler

🤖 Generated by the Agentic Engineer

Problem

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?

  1. Lint only the files our patch changes. This keeps the gate meaningful for our own code.
  2. Keep the builder on Go 1.26 until we rebase onto a Kyverno release that is clean under the new linter.
  3. 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.

Activity

  1. added theissue type on Oct 28, 2026
  2. moved this to 📥 Backlog in 🌊 Project Boardon Oct 28, 2026
  3. devantler commented on Oct 28, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

  4. coderabbitai commented on Oct 28, 2026

    @coderabbitai
    Contributor
    ⚠️ Possible Duplicate Issue(s)

    📝 Issue Planner

    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!

  5. devantler commented on Nov 1, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

  6. devantler commented on Nov 2, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Fields

    Priority

    None yet

    Effort

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions