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
Wildcard support for creation in ReplacementTransformer #4886
Wildcard support for creation in ReplacementTransformer #4886
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: KnVerey 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 |
042d65a
to
4ce0e2b
Compare
@KnVerey: 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. |
4ce0e2b
to
273fdf0
Compare
val *RNode | ||
field string | ||
matchRegex string | ||
indexNumber 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.
This field is internal and was set in one place but unused.
This approach doesn't work when multiple existing sequence elements should match, i.e. because the sequence contains maps and we're searching on a key they all contain (target all containers with a certain image would be one use case for this). PathGetter just takes the first match in that case, which is not what we want.
…e query should match multiple elements
PathGetter treats it as meaning 'last' not 'append' and does not have test coverage for its handling of this when create is set. Semantics are dubious given that multiple Replacement fieldPaths may be specified, which would cause successive appends.
a5a5469
to
f9fbbc7
Compare
rebased and ready for review @natasha41575 |
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.
The change to PathMatcher is very well done, thanks!
lgtm, couple of minor comments
kyaml/yaml/match_test.go
Outdated
|
||
func TestPathMatcher_Filter_Create(t *testing.T) { | ||
testCases := map[string]struct { | ||
name string |
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.
nit: looks like this name
field doesn't get used anywhere, do we need it?
} | ||
func fieldRetrievalError(fieldPath string, isCreate bool) string { | ||
if isCreate { | ||
return "unable to find or create field " + fieldPath + " in replacement target" |
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.
super nit: suggest quoting the fieldPath, since it's a user input value
Updated! I also realized the "find or create" error wasn't showing up in any tests, so I added another one.
Thanks! It took me a while to get there, as the commit history still shows. 😅 /label tide/merge-method-squash |
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
…igs#4886) * Ahead-of-time wildcard path expansion solution * Wrapped PathGetter solution This approach doesn't work when multiple existing sequence elements should match, i.e. because the sequence contains maps and we're searching on a key they all contain (target all containers with a certain image would be one use case for this). PathGetter just takes the first match in that case, which is not what we want. * Add creation support to PathMatcher * Regression test for existing bug when creation is enabled and sequence query should match multiple elements * PathMatcher Create tests and support for sequence appending * revert hyphen append support PathGetter treats it as meaning 'last' not 'append' and does not have test coverage for its handling of this when create is set. Semantics are dubious given that multiple Replacement fieldPaths may be specified, which would cause successive appends. * This also provides a solution to issue 1493 * Review feedback
…igs#4886) * Ahead-of-time wildcard path expansion solution * Wrapped PathGetter solution This approach doesn't work when multiple existing sequence elements should match, i.e. because the sequence contains maps and we're searching on a key they all contain (target all containers with a certain image would be one use case for this). PathGetter just takes the first match in that case, which is not what we want. * Add creation support to PathMatcher * Regression test for existing bug when creation is enabled and sequence query should match multiple elements * PathMatcher Create tests and support for sequence appending * revert hyphen append support PathGetter treats it as meaning 'last' not 'append' and does not have test coverage for its handling of this when create is set. Semantics are dubious given that multiple Replacement fieldPaths may be specified, which would cause successive appends. * This also provides a solution to issue 1493 * Review feedback
-
meaning "append" without knowing the index in advance. However, the example in replacements: Unable to add/create a new array element #4469 made me think the semantics deserve separate consideration (if you use hyphens in that example, you'll append two new things, which is not the intent). Plus PathGetter uses-
to mean "last", with untested/unclear behaviour on create. We can still do something like this if there's demand for it; I just decided it shouldn't be part of this PR.Fixes #4561
Fixes #4469
Fixes #1493