-
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
Double quotes removed from strings #4845
Comments
This is highly related to #4146, #3412 and others where the root cause is a possibly-non-string value in what Kustomize theoretically could recognize as a string field. I believe the conclusion so far has been that the quotes are being stripped as superfluous by the YAML library we are using, so although we agree with the behaviour being undesirable, the universal fix isn't obvious or simple (e.g. should we try to force the style to be preserved, and how? or should we use schema knowledge to override after the fact, and where?). /triage accepted |
@KnVerey Any update on this please? We have just hit this issue on the same version when reading config from an env file and then the value is then used to set some labels. Using kustomize v4.5.7 If we try wrap the value in double or single quotes to preserve the value as a string, we then get validation errors such as
Update 2023-03-14:
|
Facing the same problem when setting |
Any update on this? |
Also looks related to #3485 - which was closed due to vars deprecation, but the quotes issue looks identical. |
This is still an issue. Tried kustomize build with kustomize version 5.0.0:
Turns into after kustomize build:
After that i do an envsubst and replace ${TEST} with 12345. The resulting YAML isnt possible to apply with kubectl due to conversion error: |
Solution: Using block scalar style as mentioned here with Kustomize v5.0.0 works:
Now building the Kustomization, subsitute ${TEST} with 12345 and applying it with kubectl results in the following ConfigMap:
You will have a linebreak at the end of the value (
|
The same problem exists in |
Do we have any solution to above issue as I still observe this behaviour of stripping away the double quotes ? |
Replacements seems conventionally useless if it breaks quoted numbers 😕 |
Any news? |
It's quite annoying that the maintainers don't seem interested in addressing this issue. Dynamically replacing vars in the kustomize output, outside of the "kustomize process", is a totally valid workflow. A workaround is to use yq (the YAML equivalent to jq) to add back double quotes to values that are environment variables: kubectl kustomize foobar > manifest.yaml
yq -i --unwrapScalar=false '(.. |= select(. == "$*") style="double")' manifest.yaml You can then replace vars further down the pipeline, e.g. with envsubst: kubectl kustomize foobar > manifest.yaml
yq -i --unwrapScalar=false '(.. |= select(. == "$*") style="double")' manifest.yaml
envsubst < manifest.yaml | kubectl apply -f - or as a single pipeline: kubectl kustomize foobar | yq --unwrapScalar=false '(.. |= select(. == "$*") style="double")' | envsubst | kubectl apply -f - |
Describe the bug
Running kustomize removes double and/or single quotes from strings.
If a value in a config map is a template placeholder and the actual application value is not yet known because the built resources are post-processed by another process, the quotes should not be removed. Removing them can lead to producing invalid config maps. For example if the value of the placeholder is a commit SHA which just happens to be all numeric then the value in the config map is interpreted as a number by Kubernetes and rejected with a validation error.
Values in config maps should always be quoted given that they can only be strings anyways.
Files that can reproduce the issue
config-map.yaml
kustomization.yaml
Expected output
Actual output
Kustomize version
{Version:kustomize/v4.5.7 GitCommit:56d82a8378dfc8dc3b3b1085e5a6e67b82966bd7 BuildDate:2022-08-02T16:35:54Z GoOs:darwin GoArch:arm64}
Platform
MacOS M1 Monterey 12.6
The text was updated successfully, but these errors were encountered: