-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate some cfg commands #4048
Deprecate some cfg commands #4048
Conversation
3c2b446
to
64d16cf
Compare
IMO yes we can do it now. In fact, it might get us some engagement around whether it is worth providing as an "official" transformer.
Looks like it's related to setters and requires a KRM file, so yes, I think it should go.
WDYT about linking to the deprecation issue? |
64d16cf
to
2c62d22
Compare
2c62d22
to
a3d60c3
Compare
b725807
to
f95b409
Compare
f95b409
to
16dcc98
Compare
@KnVerey done, e.g.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: KnVerey, natasha41575 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This PR marks some
cfg
commands as deprecated as described in #3953, and would be a first step toward #4045.Some questions:
kustomize cfg
andkustomize fn
alpha commands #3953 about having setters as a transformer - do we need to wait for that to be done before deprecating the setters commands? Or is a release note pointing to the KRM functions enough?create-subst
- this PR marks it as deprecated, but is that what we want to do?Sample output: