helm-drift does not support kind: List pseudoresource

[ppettina]

For some reason I ended up with this in a release:

# Source: XXXX.yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: ConfigMap
  metadata:
    name: some-token-metadata
    namespace: something
    labels:
      type: token-metadata
  data:
    redacted: "true"
kind: List
metadata: {}

Note kind: List and the empty metadata. Running helm-drift produces:

$ helm drift run myrelease -n mynamespace --from-release
ERRO[0000] getting manifest information from template errored with 'failed to get name from the metadata, 'name' is not type string'
{"level":"fatal","msg":"failed to get name from the metadata, 'name' is not type string","time":"2024-12-19T17:24:36Z"}
Error: plugin "drift" exited with error

I can get away with skipping lists:

$ helm drift run myrelease -n mynamespace --from-release --skip List

YAY...! NO DRIFTS FOUND
------------------------------------------------------------------------------------
Total time spent on identifying drifts : 10.756707251
Total number of drifts found           : 0
Status                                 : SUCCESS
------------------------------------------------------------------------------------

Docs on kind: List here:
https://kubernetes.io/docs/reference/using-api/api-concepts/#collections

Some tools, such as kubectl, represent the Kubernetes collection mechanism slightly differently from the Kubernetes API itself. Because the output of kubectl might include the response from multiple list operations at the API level, kubectl represents a list of items using kind: List

I guess helm-drift should "unpack" this list and process each item separately?

[ppettina]

Similar to helm/helm#8615

[nikhilsbhat]

@ppettina, is there a specific reason for using kind: List instead of leveraging Helm templates?

Considering the current architecture of the plugin, managing this condition could be difficult. I haven't reviewed the issue yet, but I will look into it and see if I can address it within the plugin as well.

[ppettina]

@nikhilsbhat thanks for the reply, sorry checking it out now.

We have a few charts we brought in from third parties that have this issues - so nothing we brought in intentionally. This isn't blocking, but I thought reporting it would be a good thing to do nonetheless.

Also thanks on working on this tool, which I presume is on a voluntary basis.