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
fix(kubernetes): do not fail to deploy List kinds (e.g. ConfigMapList) #4501
Conversation
Fixes #4500 Co-authored-by: Srihas Konduru <srihas-g@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for figuring this out!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
@Orzelius @Walther @edvald I wonder if this would break if there was a custom resource definition with custom resources ending with |
Maybe it would be safe enough to only flatMap the List if it actually has |
I think we should only do this for resources with |
Kustomize also treats anything with |
Maybe the List is actually a CRD? Seems to be unlikely as other tools like Kustomize also treat kinds matching `*List` as lists. But add a better error message here if items contains something unexpected just in case. This logic is more or less equivalent to https://github.com/kubernetes-sigs/kustomize/blob/cf3e81b590ab1fd7fc8f50849535f44bfea0d355/api/resource/factory.go#L550
@edvald I now implemented a logic equivalent to what seems to work for Kustomize – looking ok for you? |
I still think we should only do this for core API resources, basically just |
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #4500
Special notes for your reviewer: