In replacements, the type of source value is not retained when the target fieldPath is not existent an configured with option.create: true

[ElSamhaa]

What happened?

I'm trying to override an environment variable that might or might not exist in the base. I'm using a local config as a source with the numeric value as a string.

When the base happens to have that overridden environment variable defined, it retains the type right. However, whenever the base is missing the environment variable, the env is created with the numeric value as an integer; not as a string like in the source field.

What did you expect to happen?

The type of the source value should be retained under all conditions.

How can we reproduce it (as minimally and precisely as possible)?

# resources.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: local-config
  annotations:
    config.kubernetes.io/local-config: "true"
data:
  ENV_TEST: "10"
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: alpine
    name: test

# kustomization.yaml
resources:
- resources.yaml

replacements:
- source:
    kind: ConfigMap
    name: local-config
    fieldPath: data.ENV_TEST
  targets:
  - select:
      kind: Pod
    options:
      create: true
    fieldPaths:
    - spec.containers.[name=test].env.[name=TEST].value

Expected output

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - env:
    - name: TEST
      value: "10"
    image: alpine
    name: test

Actual output

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - env:
    - name: TEST
      value: 10 # the value type is integer; does not match the type in the source (string)
    image: alpine
    name: test

Kustomize version

v5.3.0

Operating system

MacOS

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[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

[quentinus95]

/remove-lifecycle stale