checks/groups/etc silently ignored if `kind` is invalid

[technicalpickles]

It took me looking at a diff to see why this group wasn't running:

apiVersion: scope.github.com/v1alpha
kind: ScopeDoctorGrop
metadata:
  name: shell
# rest of YAML here

ScopeDoctorGrop != ScopeDoctorGroup. I was trying to manually run it, which lead to https://github.com/ethankhall/scope/issues/67

I think we def are getting to the point of needing some schema validation 😅

[ethankhall]

This is actually intended behavior at the moment. This allows additional scope sub-commands to create their own YAML.

When scope calls a sub-command, it parses all the yaml, and converts it to JSON, then writes the JSON to disk, and provides an env-var for the sub-command to use so it doesn't have to do any of the finding/yaml parsing making it easier to work with tools like jq.

Long term I think we'd want to add some sort of registry where you define the known kinds, to show a warning if it's not defined.

In the short term, we could add a warning now.

[technicalpickles]

This allows additional scope sub-commands to create their own YAML.

These are sub-commands defined by scope itself, right? Not ones that come from elsewhere (I'm thinking of gdev commands registered on the path with gdev-<whatever>)?

If it is just scope, I think it makes sense to always validate.

---

A separate thought, it could be an error if you try to run a specific subcommand, and you don't find any kinds that match. That might be more about https://github.com/ethankhall/scope/issues/67 though

[ethankhall]

The built in commands act the same as the external ones that are supported. So during the init phase everything is parsed, and then for an internal command, the parsed config is passed directly to the command, for an external sub-command the parsed YAML is converted to JSON and all written to a single JSON file that's set in an env-var.

Because there could be a different config file, with a different kind, we wouldn't want to fail on a different name.

Adding some validation where the root scope process knows about all the config types, and warn if they are not understood seems like the best path forward. Adding real validation would be best I think, akin to how K8s does it.

[ethankhall]

I've updated scope to now validate resources it knows about, but doesn't support external types yet. It does show the type when you list now, so you should be able to see a typo.

[ethankhall]

Closing, feel free to re-open if the updates to parsing don't help.