Allow kustomize CLI to add/set labels with includeSelectors: false

[margeaux-gendron]

Is your feature request related to a problem? Please describe.

Currently, kustomize edit add/set label only supports commonLabels

The introduction of the new label without selectors was intended to fix issues with dynamic labeling changes. However, I don't see a way to dynamically set these labels without selectors with the current CLI.

For example, I cannot dynamically update a version label via CI/CD, due to commonLabels updating selectors which are immutable.

Describe the solution you'd like

Update kustomize edit add/set label to use the new label format with a flag to enable/disable selectors

Describe alternatives you've considered

We are currently using a var in the labels which pulls from a version annotation, and using commonAnnotations instead to set the version dynamically, but vars are planned to be deprecated.

[GraemeF]

I was say this is a bug because running kustomize edit set label version:bar on:

labels:
- includeSelectors: false
  pairs:
    version: foo

produces:

labels:
- includeSelectors: false
  pairs:
    version: foo
commonLabels:
  version: bar

which is of course invalid:

Error: label name 'version' exists in both commonLabels and labels

[koba1t]

Are you want the below functions?

• https://github.com/kubernetes-sigs/kustomize/pull/4478
• https://github.com/kubernetes-sigs/kustomize/pull/4486

[margeaux-gendron]

Are you want the below functions?

• feat: support edit set label for labels and not only commonLabels #4478
• add: "edit add labels" command adds an option for labels without selector #4486

Those look to cover what I am asking for, yes.

[natasha41575]

/triage accepted

I will add reviewing the above PRs to my TODO list.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[sudoforge]

@natasha41575 any chance you're able to prioritize those PRs?

i went hunting for why the CLI did not support editing labels (vs commonLabels) today and happened upon this issue. i think this is a fairly necessary feature, and its lack of inclusion when labels were added should be seen (in my opinion) as an oversight, and the current behavior as broken.

if there is anything that either PR needs changed that either author is unwilling or unavailable to change, i will happily take over. this is critical functionality for setting labels with dynamic values.