-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
fix: patch additions honor source key style #5196
fix: patch additions honor source key style #5196
Conversation
When a patch appends a new node, it should honor the key style from the patch. Prior to this commit, no style was applied, leading to problems when the key value could be interpreted as a different type based on its content. For example, "9110" needs quoting to ensure it is seen as a string in yaml.
Hi @ephesused. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
/triage accepted |
/ok-to-test |
name: blabla | ||
namespace: blabla-ns | ||
data: | ||
"6443": "foobar" |
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.
Could you consider adding a test case when the key-value has "6443"
and 6443
?
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.
I'm happy to extend or add other tests, but I'm not quite following the scenario you'd like me to test. Are you asking that this test to change its current input "6443" entry to:
"6443": 6443
And leave the patch entry like so?
"6443": "barfoo"
That would mean this test would be exercising different value types.
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.
I'm sorry for writing a misreadable comment.
I just want to add to tests that mixed the same name string key and int key.
Ex.
- base configMap has
"6443": "foobar"
and a patch has6443: "barfoo_int"
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.
Done - note that this scenario mirrors one that I discussed with @KnVerey in my earlier attempt.
A key point to make is that I'm intending this fix to be targeted at the specific issue in #4928: the key style of a node that's newly created in a merge.
This PR is not intended to alter the existing key style behavior for patches (which, I admit, is somewhat confusing). In that context, the adjusted test case we are discussing falls outside of the scope of what this PR changes. The current behavior for kustomize when input and patch have a matching key is to retain the key style of the input. This PR does not change that behavior.
Edited to fix a bad link.
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.
In that context, the adjusted test case we are discussing falls outside of the scope of what this PR changes.
I understood this sentence. I want to keep until behavior with test cases.
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.
So I want to say that we need to add test cases while keeping at the tests from 691b7d1.
Could you add test cases using the int key under your tests?
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.
Apologies - I believe I've got it right this time. Thanks for your patience.
This PR has multiple commits, and the default merge method is: merge. 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/test-infra repository. |
Thanks @ephesused ! |
any updates on this? |
Like the other PR, would you mind pushing a dummy commit to see if it retriggers the tests? |
I simply merged to make this PR current. I see the workflows waiting to run, pending approval from a maintainer. Thanks! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ephesused, 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 |
/lgtm |
When a patch appends a new node, it should honor the key style from the patch. Prior to this commit, no style was applied, leading to problems when the key value could be interpreted as a different type based on its content. For example, "9110" needs quoting to ensure it is seen as a string in yaml.
Fixes #4928
This PR replaces #5005, where I messed up my working branch. Given circumstances, I figured it was simpler to just cut a new PR.