Code generation misses kind field in the CustomResourceDefinitionNames

[hnaderi]

Hi @hnaderi - I'm back from a long weekend, hope you're well. 😄

So I've done some more digging and the culprit is here!

final case class CustomResourceDefinitionNames(
  plural : String,
  singular : Option[String] = None,
  listKind : Option[String] = None,
  categories : Option[Seq[String]] = None,
  shortNames : Option[Seq[String]] = None
)

Note that this is missing the kind field. What's interesting is that I followed your plugin code and that led me to the following understanding:

1. CustomResourceDefinitionNames is a generate class
2. The KubernetesSpecPlugin generates it by reading the k8s spec based on the version supplied in the build.sbt file.
3. Having downloaded the spec as json, it parses and writes the details into src_managed.

So far so good. (I like how you defined the plugin to do that, btw - nice!)

The trouble is that it isn't working correctly. If you go to the spec, you can clearly see the kind field defined, and also declared as required in the JSON schema definition - but for some reason, this is being ignored.

Here's the spec, search for CustomResourceDefinitionNames.
https://raw.githubusercontent.com/kubernetes/kubernetes/v1.27.1/api/openapi-spec/swagger.json

...and you get this:

    "io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1.CustomResourceDefinitionNames": {
      "description": "CustomResourceDefinitionNames indicates the names to serve this CustomResourceDefinition",
      "properties": {
        "categories": {
          "description": "categories is a list of grouped resources this custom resource belongs to (e.g. 'all'). This is published in API discovery documents, and used by clients to support invocations like `kubectl get all`.",
          "items": {
            "type": "string"
          },
          "type": "array"
        },
        "kind": {
          "description": "kind is the serialized kind of the resource. It is normally CamelCase and singular. Custom resource instances will use this value as the `kind` attribute in API calls.",
          "type": "string"
        },
        "listKind": {
          "description": "listKind is the serialized kind of the list for this resource. Defaults to \"`kind`List\".",
          "type": "string"
        },
        "plural": {
          "description": "plural is the plural name of the resource to serve. The custom resources are served under `/apis/<group>/<version>/.../<plural>`. Must match the name of the CustomResourceDefinition (in the form `<names.plural>.<group>`). Must be all lowercase.",
          "type": "string"
        },
        "shortNames": {
          "description": "shortNames are short names for the resource, exposed in API discovery documents, and used by clients to support invocations like `kubectl get <shortname>`. It must be all lowercase.",
          "items": {
            "type": "string"
          },
          "type": "array"
        },
        "singular": {
          "description": "singular is the singular name of the resource. It must be all lowercase. Defaults to lowercased `kind`.",
          "type": "string"
        }
      },
      "required": [
        "plural",
        "kind"
      ],
      "type": "object"
    }

Note:

        "kind": {
          "description": "kind is the serialized kind of the resource. It is normally CamelCase and singular. Custom resource instances will use this value as the `kind` attribute in API calls.",
          "type": "string"
        },

and

      "required": [
        "plural",
        "kind"
      ],

What do you think is going on?

Originally posted by @davesmith00sky in #96 (comment)

[hnaderi]

@davesmith00sky You can access the fixed version here (after the CI passes):

ThisBuild / resolvers ++= Resolver.sonatypeOssRepos("snapshots")
libraryDependencies ++= Seq(
  "dev.hnaderi" %% "scala-k8s-http4s-ember" % "0.11-9bad70e-SNAPSHOT"
)

Note that there are some minor breaking change to the client from other developments, so you might want to check the docs again, also feel free to ask questions and your feedback is highly appreciated as always!

[davesmith00sky]

@hnaderi - Works like a charm! 😄

Thank you very much for the fix, I'll carry on and report back if I find any more bumps in the road.