cnoe-io / cnoe-cli

CNOE CLI
Apache License 2.0
8 stars 4 forks source link

fix integer type handling #17

Closed nabuskey closed 11 months ago

nabuskey commented 12 months ago

Fixes the issue where int is passed to the unstructured calls.

When you try to run the cli against all composition definitions available in the crossplane on eks repo, the following is shown.

./main template crd -i ~/repos/crossplane-aws-blueprints/compositions/aws-provider/eks -o /tmp/out --templatePath ~/repos/cnoe/cnoe-cli/config/templates/k8s-apply-template.yaml
2023/09/22 11:05:55 processing 5 definitions
2023/09/22 11:05:55 processing resource at /Users/mccloman/repos/crossplane-aws-blueprints/compositions/aws-provider/eks/autoscaler.yaml
2023/09/22 11:05:55 processing resource at /Users/mccloman/repos/crossplane-aws-blueprints/compositions/aws-provider/eks/definition.yaml
panic: cannot deep copy int

The k8s.io/apimachinery/pkg/runtime.DeepCopyJSONValue expects int64 only, not int. Int type is returned by the yaml library. To ensure int64 is returned, we can just use the k8s yaml library instead. This is less efficient but for generation purposes, I think it's fine.

As a result of switching the library, the json tags on the document struct is now respected. When generating from XRDs, this results in generation of files named with the claim kind only. (e.g. cdn.yaml as opposed to awsblueprints.io.cdn.yaml) I don't think naming the file with the kind string is intended. I changed it to follow the same pattern.