You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement related to a problem? Please describe.
I am extensively using Flux2 for Kubernetes GitOps deployments. They support variable substitution in YAML files as shown in https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution In essence, they just preprocess all YAML files and replace any ${variable_name} with whatever you have defined. However, when combining this with schema validation, whenever you use variables that require integers, numbers, etc break.
I think it makes sense that if you perform a manual cast like !!int the scheme validation system should simply accept that whatever follows is an integer. Not also try to cast it to an integer itself and if that fails, throw a type error.
Describe alternatives you have considered
I see no alternatives to fix this problem.
Additional context
The question is, could this be a breaking change as now in theory when you write !!int, there is no actual validation performed anymore on the string value (if it can be converted to an int). My personal opinion is that whenever you add a tag, you perform an explicit cast and don't care about more type checking.
The text was updated successfully, but these errors were encountered:
Is your enhancement related to a problem? Please describe.
I am extensively using Flux2 for Kubernetes GitOps deployments. They support variable substitution in YAML files as shown in https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution In essence, they just preprocess all YAML files and replace any ${variable_name} with whatever you have defined. However, when combining this with schema validation, whenever you use variables that require integers, numbers, etc break.
Given the following scheme
This obviously works
This also works nicely
But for the integer case, this does not work and will still throw an integer type error!
Describe the solution you would like
I think it makes sense that if you perform a manual cast like
!!int
the scheme validation system should simply accept that whatever follows is an integer. Not also try to cast it to an integer itself and if that fails, throw a type error.Describe alternatives you have considered
I see no alternatives to fix this problem.
Additional context
The question is, could this be a breaking change as now in theory when you write
!!int
, there is no actual validation performed anymore on the string value (if it can be converted to an int). My personal opinion is that whenever you add a tag, you perform an explicit cast and don't care about more type checking.The text was updated successfully, but these errors were encountered: