-
Notifications
You must be signed in to change notification settings - Fork 594
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
Variable substitution results in validation error: cannot convert int64 to string #4154
Variable substitution results in validation error: cannot convert int64 to string #4154
Comments
I found this ugly workaround in the meantime: stringData:
TELEGRAM_CHAT_ID: ${double_quote:="}${telegram_chat_id}${double_quote:="} |
That is horrible, but I like it because you figured out another workaround that I haven't seen yet. (Most of the old ones don't work anymore.) But someone else figured out (they read the YAML spec, which says) that you can prevent quoted strings from becoming something else when they are parsed and reparsed by putting a type tag, or hint, reference from the spec here (2.4. Tags): stringData:
TELEGRAM_CHAT_ID: !!str "${telegram_chat_id}" This should do it 🤞 I haven't tested this myself, but I've been given this info by another user who reported the solution in Slack about two weeks ago. I think this is the proper right way to solve it! Please let us know if it works. |
No, this doesn't work it seems. |
For the fun of it, I also tried stringData:
TELEGRAM_CHAT_ID: "!!str ${telegram_chat_id}" which, according to stringData:
TELEGRAM_CHAT_ID: '!!str ${telegram_chat_id}' and when deployed the secret correctly contains |
That's right... the example they provided was actually this one:
I guess that's not what's in the YAML spec, but it should work. I'm guessing it would work, except for you're doing it in a postbuild substitution in a kustomize generator. (Can you provide the complete example? It takes a bit of time to reproduce the situation, and I'm sure it's some combination of factors that won't be easy to come by without making up some details, for example please provide the kustomization files and show how you are engaging the postbuild substitution and any generator configs that you mentioned in the top post) I am sure the problem has to do with the order of the parsing of the YAML along with the building and the substitution. If the YAML spec says to put the tag outside of the quotes, I wouldn't put it inside the quotes, (I don't think this matters however as I mentioned the person who reported this workaround two weeks ago put their tags inside the quotes.) They didn't say anything about a substitution though. I guess that is the confounding factor. I don't know any way to solve this. |
Just another idea, have you tried omitting the quotes entirely? (Only use the |
Nope, no quotes also doesn't work. |
This got me thinking and I think the best solution is to place the I just tested this and it worked wonderful. As far as I can reason about this, the trick is that the tag stringData:
TELEGRAM_CHAT_ID: ${str_tag:=!!str}${telegram_chat_id} But I think it is nicer to just have the P.S. Maybe this can be documented in variable substitution docs? |
Describe the bug
I have a secret which gets generated as
where
telegram_chat_id
is a number represented as a string, e.g. defined in acluster-vars
secret asyet when this is generated, it produces a number, i.e.
resulting in a
when trying to deploy this secret.
It does not matter whether the interpolated value is quoted as
'${telegram_chat_id}'
or"${telegram_chat_id}"
, the secret is always generated as an unquoted number.Steps to reproduce
Create a secret by a interpolating a value containing a number.
Expected behavior
Don't change the value type to a number and correctly generate the secret with
Screenshots and recordings
No response
OS / Distro
macOS 12.6.3
Flux version
2.0.1
Flux check
► checking prerequisites
✔ Kubernetes 1.27.3 >=1.24.0-0
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v0.35.0
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.0.1
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v1.0.0
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v1.0.1
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta2
✔ buckets.source.toolkit.fluxcd.io/v1beta2
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1beta2
✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1
✔ helmrepositories.source.toolkit.fluxcd.io/v1beta2
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta2
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed
Git provider
GitHub
Container Registry provider
No response
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: