Link explicit Pod PriorityClass and RuntimeClass references

[nadaverell]

Pod details omit links to the classes that govern priority and runtime selection. Show nonempty spec.priorityClassName and spec.runtimeClassName in the existing Status section, linking to their canonical API groups with cluster scope. Reuse the existing ResourceLink and class renderers.

These are explicit Pod declarations. Numeric priority and absent names do not infer a class, and opening RuntimeClass is not proof that its handler is available on a Node. Scope: shared Pod drawer, including SDK consumers on their normal update. Class reverse consumers, workload-template references, resourceContext, graph enrollment and Diagnose expansion are separate follow-ups.

Validation: 16 current and existing Pod renderer tests pass, including actual click handlers and non-inference. Type checking and the full frontend/embed/backend build pass. Actual isolated-kind browser clicks reach both group-qualified cluster-scoped class drawers, with zero page errors; one settled capture was inspected. Existing resource-read authorization and missing/unavailable target states remain in use.

---

Note

Low Risk
Read-only UI additions in the Pod renderer with navigation via existing ResourceLink; behavior is covered by new tests and does not change auth or data handling.

Overview
Pod details in the shared drawer now surface Priority Class and Runtime Class when spec.priorityClassName and spec.runtimeClassName are set, each as a ResourceLink to the cluster-scoped priorityclasses (scheduling.k8s.io) and runtimeclasses (node.k8s.io) resources. Numeric spec.priority alone does not show a priority class row.

New PodRenderer tests assert click navigation uses the correct kind, API group, and empty namespace, and that class labels are omitted when only a numeric priority is present.

^{Reviewed by Cursor Bugbot for commit 48046bd. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Link explicit Pod PriorityClass and RuntimeClass references

✨ Enhancement 🧪 Tests 🕐 10-20 Minutes

AI Description

• Show explicitly named PriorityClass and RuntimeClass references in the Pod Status section.
• Open the cluster-scoped class drawers using their canonical API groups.
• Test click navigation and ensure numeric priority alone does not imply a class.

Diagram

graph TD
  A["Pod spec"] --> B["Pod Status"] --> C["ResourceLink"] -->|"scheduling.k8s.io"| D["PriorityClass drawer"]
  C -->|"node.k8s.io"| E["RuntimeClass drawer"]

Loading

High-Level Assessment

Reuse of ResourceLink and the existing class renderers is appropriate for explicit Pod references. Inferring a class from numeric priority would misrepresent the Pod declaration, while adding a separate lookup would expand scope without improving these links.

Files changed (2) +28 / -0

Enhancement (1) +6 / -0

PodRenderer.tsxShow explicit Pod class links in Status +6/-0

Show explicit Pod class links in Status

• Conditionally displays priority and runtime class names through ResourceLink. Supplies each class’s canonical API group and leaves namespace empty for cluster-scoped navigation.

packages/k8s-ui/src/components/resources/renderers/PodRenderer.tsx

Tests (1) +22 / -0

PodClassReferences.test.tsxTest explicit Pod class navigation and non-inference +22/-0

Test explicit Pod class navigation and non-inference

• Clicks both class links and verifies their kinds, API groups, and empty cluster-scoped namespaces. Confirms that numeric priority without class names produces neither class property.

packages/k8s-ui/src/components/resources/renderers/PodClassReferences.test.tsx

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗