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
Currently, we remove labels based on a list of YAML keys which could break the initial chart. For example, if a custom resource definition contains a key with the same name as provided in the list to remove and this key has nothing to do with labels, then it will break:
apiVersion: custom/v1
kind: MyCustomResource
metadata:
name: my-custom-resource
spec:
something:
labels: # << this shouldn't be removed but helm-convert will remove it
someConfig: someValue
someMoreConfig:
labels: ## << this should be removed
some: label
someMoreNestedConfig: someValue
To prevent this to happen, we could create a map of safe path per resource using the following format which could be parsed into a GVK type <api group>/<api version>/<kind>:
Currently, we remove labels based on a list of YAML keys which could break the initial chart. For example, if a custom resource definition contains a key with the same name as provided in the list to remove and this key has nothing to do with labels, then it will break:
To prevent this to happen, we could create a map of safe path per resource using the following format which could be parsed into a GVK type
<api group>/<api version>/<kind>
:By doing so we would need to provide the path of all the resources and make it possible to pass custom path via the CLI.
For natives resources (apps/v1, policy/v1beta1, etc.). We can keep the current behavior.
The text was updated successfully, but these errors were encountered: