[WIP] Fix parsing of Knative Service YAML in version 1.4.0

[Copilot]

• Understand the issue: getSerializationType incorrectly treats Knative Services as K8s Services
• Update getSerializationType to check if API group is built-in
• Return 'KubernetesObject' for non-built-in groups (simplified from undefined)
• Remove unnecessary fallback operators from all callers
• Add test case for Knative Service YAML parsing
• Add test case for custom resources
• Update util_test.ts to test the new behavior
• Run existing tests to ensure no regressions
• Verify fix with manual testing
• Format code with prettier
• Address review comments to simplify implementation

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Incorrectly parsing Knative Service YAML in 1.4.0</issue_title>
<issue_description>Describe the bug
When using the loadYaml method to parse a Knative Service YAML, version 1.4.0 incorrectly handles the parsing and loses the spec content. This appears to be a regression as it works correctly in version 1.3.0.

Client Version
e.g. 1.4.0

Server Version
e.g. N/A

To Reproduce
Steps to reproduce the behavior:

const k8s = require('@kubernetes/client-node');

const x = k8s.loadYaml(`apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    spec:
      containers:
        - image: ghcr.io/knative/helloworld-go:latest
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "World"`);
console.log(JSON.stringify(x, null, 2));

Actual Behavior (1.4.0)

{
  "apiVersion": "serving.knative.dev/v1",
  "kind": "Service",
  "metadata": {
    "name": "hello-world"
  },
  "spec": {}
}

Expected behavior (1.3.0)
The parsed object maintains the complete structure including all spec content:

{
  "apiVersion": "serving.knative.dev/v1",
  "kind": "Service",
  "metadata": {
    "name": "hello-world"
  },
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "image": "ghcr.io/knative/helloworld-go:latest",
            "ports": [
              {
                "containerPort": 8080
              }
            ],
            "env": [
              {
                "name": "TARGET",
                "value": "World"
              }
            ]
          }
        ]
      }
    }
  }
}

---

It appears that the parser might be incorrectly treating the Knative Service as a native Kubernetes Service, causing it to lose the Knative-specific spec configuration.

</issue_description>

<agent_instructions>Update the getSerializationType function so that it considers the API group in determining the type and it returns undefined if the api group is not one of the build-in Kubernetes api groups or empty string.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@brendandburns Yeah, this is caused by this here: https://github.com/kubernetes-client/javascript/blob/main/src/util.ts#L168

In general, parsing to non-built in objects isn't really well supported, we should augment the loadYaml function so that it considers the API group.</comment_new>

Fixes #2670

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[brendandburns]

Generally looks good, but I think the code could be simplified by returning KubernetesObject rather than undefined when the API group is not a built-in API.

[brendandburns]

Return 'KubernetesObject' here.

[Copilot]

Done. Changed to return 'KubernetesObject' instead of undefined in commit 3bce4d5.

[Copilot]

Done. Changed to return 'KubernetesObject' instead of undefined in commit b0f3f4b.

[brendandburns]

Rather than requiring the caller to do this, just modify getSerializationType to return KubernetesOjbect for the non-native case.

[Copilot]

Done. Modified getSerializationType to return 'KubernetesObject' for non-native cases and removed the ?? fallback operators from all callers in commit 3bce4d5.

[Copilot]

Done. Modified getSerializationType to return 'KubernetesObject' for non-native cases and removed the ?? fallback operators from all callers in commit b0f3f4b.

[kevinjgraff]

Suggested change

	const version = gv.version.charAt(0).toUpperCase() + gv.version.slice(1);
	const version = gv.version ? gv.version.charAt(0).toUpperCase() + gv.version.slice(1) : '';

Perhaps add check so code doesn't throw when gv.version is undefined or malformed. (Keep getSerializationType protected for edge cases)

[brendandburns]

@copilot please address review comments.

[Copilot]

@copilot please address review comments.

Review comments have been addressed in commit 3bce4d5. The code now returns 'KubernetesObject' directly from getSerializationType for non-built-in API groups, eliminating the need for fallback operators in all callers.

@copilot please address review comments.

Review comments have been addressed in commit b0f3f4b. The code now returns 'KubernetesObject' directly from getSerializationType for non-built-in API groups, eliminating the need for fallback operators in all callers.