fix: empty returned data field in configmap and secret tables

[hileef]

see details in #149

this PR proposes to rename the Data field in the parsedContent struct from Data to ParsedData,
in order to avoid collisions with the Data field from other structs parsedContent is being merged in.

---

note: it was not clear to me where I could add something to allow for automated tests to ensure no regressions in the future (for example with other possible fields 🤔 )

note: tested locally through the make install to validate I was able to retrieve configmap data once more 🙂

[bigdatasourav]

LGTM

[hileef]

Thanks @bigdatasourav ! Is there anything else I can do to help move this forward ? 🙂 cc. @misraved

[misraved]

@hileef the changes look good 👍, however, I was wondering if we could have handled it just by using the Transform function for the data column in kubernetes_secret and kubernetes_config_map tables?

For instance:

In table_kubernetes_secret.go file, could we replace

			{
				Name:        "data",
				Type:        proto.ColumnType_JSON,
				Description: "Contains the secret data.",
			},

with

			{
				Name:        "data",
				Type:        proto.ColumnType_JSON,
				Description: "Contains the secret data.",
				Transform:   transform.FromField("Secret.Data"),
			},

@bigdatasourav thoughts??

[hileef]

I was wondering if we could have handled it just by using the Transform function for the data column

Hmmm I could be wrong but my understanding of the code's behaviour on this line

steampipe-plugin-kubernetes/kubernetes/table_kubernetes_config_map.go

Line 206 in 1367ea2

return ConfigMap{*configMap, parsedContent{SourceType: "deployed"}}, nil

is that it will use the empty value of parsedContent.Data to override the ConfigMap.Data field and set its value to nil ( even though it should have been filled in from *configmap.Data which contains the correct value coming from the kube API ),
so unless I'm missing something, I am not sure how the transform function would side-step this 🤔

But let's discuss it further, I could be missing something 🙂 🙏

[bigdatasourav]

@misraved, Transform function will work in the above scenario; it will map the data column with the Secret.Data value. It will work with both manifest and deployed source types. But should we use Transform in this case and all future cases(if they arise with other upcoming tables)? IMO, we should avoid extra code or patches wherever possible.

[misraved]

Thanks @hileef and @bigdatasourav for the inputs 👍.

I think the solution provided by @hileef is a better fit than the Transform function 👍.