Add Node Selection Capability to kit info Command for Enhanced Kitfile Parsing

[gorkem]

Describe the problem you're trying to solve When using the Kit CLI on CI/CD platforms, there is often a need to extract specific information from selected nodes within a Kitfile. Currently, users must rely on additional tools like yq to parse and filter this data, adding unnecessary complexity and dependencies to CI/CD pipelines.

Describe the solution you'd like Enhance the kit info command to include a node selection feature like yq selectors. This would allow users to directly specify paths to nodes within a Kitfile, simplifying the process of retrieving targeted information without needing external tools.

Describe alternatives you've considered While yq can be used as a workaround to pipe and filter the output of the Kit CLI, this approach requires an additional tool, which complicates CI/CD configurations.

[srikary12]

I would like to take this up and work on it.

[gorkem]

Sounds good. Assigned.

[srikary12]

The expecttation is to add optional node after kit info command to display specific node. If nothing is mentioned full info needs to be displayed. Works?

[gorkem]

We can introduce a filter flag --filter so kit info displays the full info kit info --filter .model.path prints only the model path.

[srikary12]

Quick question. Can I use yqlib package to acheive the same or has to be developed in house?

[amisevsk]

I would be open to a PR that used yqlib, though I suspect it may be a bit of using a sledgehammer to drive a nail situation. The library is capable of a lot of manipulation, and we're really only concerned with simple access at the moment.

[srikary12]

I'll be building something custom then. Any approach or suggestions?

[srikary12]

@amisevsk Using reflect package I've tried adding the functionality. Need guidance with some of the pending items.

• What to do if the filter if a struct, e.g., -f model. I'm able to fetch the struct should I display in YAML or show an error?
• Suggest if I'm missing something or refractoring is needed.

[amisevsk]

@srikary12 I haven't looked into it too much, but I figure that since we have the unmarshalled struct (i.e. the Kitfile) we should just use the filter to walk that struct and marshal the resulting field.

Suppose the user passes -f ".model" (c.f. kit info <model> | yq '.model'). Then the Go code would look something like

// config := <resolved Kitfile from ResolveManifestAndConfig(...)>
filteredField := config.model

buf := new(bytes.Buffer)
enc := yaml.NewEncoder(buf)
enc.SetIndent(2)
if err := enc.Encode(filteredField); err != nil {
  // handle err
}
fmt.Println(string(buf.Bytes()))

(This assumes that using reflect to walk the struct is... simple enough. I've been working in TypeScript lately so I forget how marshalling reflected structs works :) )

Again, though, I haven't tried it out myself so I may be missing something. If this is looking ugly or difficult, feel free to submit a PR using yqlib and I will review. The reason for my gut take on yqlib is that it's designed to handle arbitrary yaml and parse it, whereas in our case we have a defined structure to work with -- I'm very ready to be wrong here :)

[srikary12]

I'll the required changes and mark it for review. I've expected the same inputs from you. I'll have to marshall them and display.

Thanks for the inputs.