kubectl alpha kuberc set command clears existing options when --overwrite is used without --option

[kfess]

What happened?

I was testing the new kubectl alpha kuberc set command (added in kubernetes/kubernetes#135003) in the local environment. I discovered what appears to be unintended behavior when updating existing configurations without specifying --option flags.

When updating an existing defaults/alias entry with --overwrite but without any --option flags, the existing options are cleared (set to nil).

I wrote a simple test case to verify this behavior: ref: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kubectl/pkg/cmd/kuberc/set_test.go

{
    name: "overwrite existing defaults without options",
    existingKuberc: `apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
defaults:
- command: get
  options:
  - name: output
    default: wide
`,
    options: SetOptions{
        Section:   sectionDefaults,
        Command:   "get",
        Options:   []string{},  // No options
        Overwrite: true,
    },
    expectedPref: &v1beta1.Preference{
        Defaults: []v1beta1.CommandDefaults{
            {
                Command: "get",
                Options: nil,  // existing options are cleared
            },
        },
    },
},

The test passes, which means the current implementation clears existing options when --overwrite is used without any --option flags. In the same way, for alias, without specifying --option flags, existing options are also cleared.

What did you expect to happen?

Existing options are preserved when --options flags is not provided. I am not sure this behavior is intentional or not.

How can we reproduce it (as minimally and precisely as possible)?

1. Clone kubernetes/kubernetes repository
2. Add the test case above to staging/src/k8s.io/kubectl/pkg/cmd/kuberc/set_test.go
3. Run: go test ./staging/src/k8s.io/kubectl/pkg/cmd/kuberc/

Anything else we need to know?

I can submit a follow-up PR if this behavior is considered unintended. Either way, I think adding explicit test cases for this behavior would be valuable to document the intended design.

Kubernetes version

Current master branch

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[kfess]

/sig cli

[ardaguclu]

/transfer kubectl I think, it should not be cleared, if options are not passed. This sounds like a bug to me. Feel free to open a PR with a test case, I'd gladly review it. Thank you.

/triage accepted /priority backlog /cc @soltysh

[kfess]

Thanks for confirming this is a bug. I'll work on a follow-up PR to fix this behavior.

/assign