Related issues:
* https://github.com/kubernetes-sigs/kustomize/issues/5031
* https://github.com/kubernetes-sigs/kustomize/issues/5171
After noting this behaviour was not present in
d89b448c74 a `git bisect` pointed to the
change 1b7db20504. The issue with that
change is that upon seeing a `null` node it would replace it with a node
whose value was equivalent but without a `!!null` tag. This meant that
one application of a patch would have the desired approach: the result
would be `null` in the output, but on a second application of a similar
patch the field would be rendered as `"null"`.
To avoid this, define a new attribute on `RNode`s that is checked before
clearing any node we should keep. The added
`TestApplySmPatch_Idempotency` test verifies this behaviour.
See also https://github.com/kubernetes-sigs/kustomize/pull/5365 for an
alternative approach
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.
- When merging (3way) resources use the patch strategy from the openAPI if the definition exists for the field
- Allow disabling of guessing patch strategy merge keys when no definition exists
- Support defining strategy and key directly on configuration fields through line and header coments
- Support attaching schema to parent fields of lists, and propagating -- e.g. that a field is a PodTemplate
dropping the node style creates a compatibility issue where quotes around "on" are dropped
because yaml.v3 interprets it as a string.
other yaml parsers interpret on as a bool value, and parse it as a bool rather than string.
fix: retain the original style so it is kept as quoted.
- fmt: don't drop the styles
- merge2: keep the style when merging elements
- setting a field: if changing the value of a scalar field, retain its style by default
