Add ability to edit non-common labels to kustomize CLI tool

[budjb]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

It would be very helpful for the kustomize tool to have the ability to add/set the value of a label in the kustomization file. Currently, kustomize edit set label affects commonLabels, whose functionality may be undesirable due to its behavior of modifying selectors as well. Non-common labels fit the use case of adding labels to all objects and optionally their templates and selectors, however, there is no CLI capability currently to allow an edit of labels values without having to resort to using tools such as sed or scripted patch creation.

Why is this needed?

It's a common use case to update the labels of kubernetes objects when deploying new releases of an application. Additionally, repeating labels throughout a series of kubernetes objects is a bit verbose. I am specifically attempting to solve for setting the app.kubernetes.io/version label on all objects I'm creating through kustomize, as well as adding the tags.datadoghq.com/version label on a deployment and its template.

Assigning the label and its value is easily accomplished using the labels functionality and patches or replacements, however, the value of the version may not be known until build-time.

To be clear, the intent of this request is not to templatize a kustomization project, but rather to update a kustomization file's label value. This follows the same pattern as setting the image tag through the command line using the kustomize CLI tool.

Can you accomplish the motivating task without this feature, and if so, how?

Currently, other tools must be used to accomplish this functionality. Clever use of sed allows replacement of values on the command line, and generating dynamic patches on the command line also suffice. I would argue that these are not ideal, as the kustomize tool allows editing of various other components of a kustomization file as first-class citizens.

What other solutions have you considered?

n/a

Anything else we should know?

The underlying intent of this request is to be able to modify the kustomize project in a CI/CD pipeline without having to resort to external tooling as mentioned above.

Feature ownership

• I am interested in contributing this feature myself! 🎉

[koba1t]

I understand we already can run kustomize edit add labels without common labels.
#4486

And kustomize edit set labels is in progress here.
#4478

Could you check if the above PRs resolve your use case?

/kind feature
/triage needs-information

[koba1t]

/area cli

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue 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.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions 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.