fix: kindIs function documentation #1653
Conversation
| @@ -2016,10 +2016,10 @@ The above would return `string`. For simple tests (like in `if` blocks), the | |||
| `kindIs` function will let you verify that a value is a particular kind: | |||
|
|
|||
| ``` | |||
| kindIs "int" 123 | |||
| kindIs "float64" 123 | |||
There was a problem hiding this comment.
This is more complicated than it seems. Even if I go back to the issue this is about.
The following will return true in a template.
kindIs "int" 123
See https://go.dev/play/p/kUCfwEQzeoh for an example that shows exactly this.
The problem in the original one is that 123 in the values.yaml file is parsed by the k8s yaml parser. The spec has data types for both integers and floating point numbers. But, the Kubernetes YAML parser turns any number into a float64. The following is a comment from that package:
// - This decodes any number (although it is an integer) into a float64 if the type of obj is unknown, e.g. *map[string]interface{}, *interface{}, or *[]interface{}. This means integers above +/- 2^53 will lose precision when round-tripping. Make a JSONOpt that calls d.UseNumber() to avoid this.
If you use an integer right in the template it will return true. If you use a number passed from the values.yaml file it will need to be a float64.
Is there a way we can make this more clear?
Signed-off-by: Terry Howe <[email protected]>
|
Instead of highlighting one example that's inconsistent with the expectations, I think it would be better to add details about how such errors can be debugged. Or even better, warn to not use the kindIs at all, and instead throw errors when a conversion / assertion fails. Failing fast with any kind of configuration errors is the best strategy anyway. |
The
kindIsfunction does not work as documented because the underlying library used for parsing stores number values asfloat64Closes: #1532