Make batch workloads first-class across Applications and workload views

[nadaverell]

Summary

Makes Jobs, CronJobs, Argo Workflows, and KEDA ScaledJobs first-class operational workloads instead of forcing serving-workload concepts such as replica readiness onto them.

The UI now distinguishes stable definitions and launchers from retained run instances and execution nodes, so operators can move from an Application to a specific run, understand what created it, inspect where it failed, and use the same selection in Overview and Logs.

What changed

A consistent batch workload model

• Supports direct Job and Workflow runs plus histories for CronJob, ScaledJob, CronWorkflow, WorkflowTemplate, and ClusterWorkflowTemplate.
• Adds an RBAC-aware run-history endpoint with launcher and definition references, retained-object counts, terminal state, timing, Pod outcomes, and resource duration.
• Uses owner references for CronJob, ScaledJob, and CronWorkflow attribution, including partial-RBAC cases where the parent itself is not listable.
• Treats retained Kubernetes objects as retained history rather than implying durable or all-time history.

Truthful Applications surfaces

• Replaces replica-oriented Ready semantics with Runtime for batch applications.
• Derives pure-batch status from active, suspended, latest succeeded, latest failed, or idle state instead of historical failure counts.
• Keeps serving availability as the app-level verdict for mixed service and batch applications while surfacing batch failures as a separate runtime signal.
• Removes generated Jobs and Workflows as duplicate applications when they belong to a launcher or definition.
• Shows batch-aware facts and workload rows in Application detail without repeating the same activity in multiple cards.

Run-focused workload experience

• Makes the selected run URL-owned through ?run=kind/namespace/name and shares it between Overview and Logs, including cold deep links and expired-run fallback.
• Adds a searchable/filterable retained-run rail with compact Pod outcome, duration, and status information.
• Organizes Overview into Selected run, Run context, definition or schedule configuration, Execution, and Activity.
• Links launcher and definition references in context, including exact Argo node-level template references where available.
• Replaces the ambiguous Workflow lineage surface with a deterministic Execution hierarchy that renders each node once and keeps failing paths visible in large graphs.
• Shows short Activity lists in full; longer lists default to significant events with an explicit expansion.
• Keeps controller errors out of the primary fact area and exposes the full message through a collapsed Failure details row.
• Keeps Logs on the same run selection, polls while runs are active, shows Argo step metadata, and provides actionable empty-log recovery commands.

Argo and topology behavior

• Reads storedWorkflowTemplateSpec for resolved execution structure and image attribution when the original template is unavailable.
• Connects Workflow definitions and runs in frontend and server-side neighborhood views.
• Bounds large run fan-outs while preserving the eight oldest active runs plus representative failed and successful outcomes, with explicit truncation wording.
• Adds ScaledJob and ClusterWorkflowTemplate topology/filter support and deterministic sampling for timestamp-less runs.

Testing

• git diff --check
• make tsc
• make test
• make build
• go test ./internal/server ./internal/mcp
• go test ./... from pkg/topology
• 74 focused shared-UI tests covering application runtime, Workflow execution parsing, topology sampling, and Application detail
• Visual-tested successful and failed WorkflowTemplate runs, Activity sizing, expandable failure details, cold run deep links, run-preserving Logs navigation, and empty-log recovery against GKE nonprod-cluster-us-east1

Notes

• Run history remains bounded by objects retained in Kubernetes; durable execution history is outside this PR.
• The live cluster provided WorkflowTemplate, Workflow, CronWorkflow, CronJob, and Job coverage. ScaledJob and ClusterWorkflowTemplate paths are covered by backend and UI tests but did not have live instances available for screenshots.
• The broadest risk is incorrect aggregation across serving and batch workloads. The implementation keeps those status models separate and covers pure-batch, mixed-app, ownership, RBAC, retained-history, and topology scenarios in tests.

---

Note

Medium Risk
Broad changes to application aggregation, issue classification, and log/run APIs could mis-rank health or mis-attribute runs if ownership/template refs are wrong; paths are heavily tested but live ScaledJob/ClusterWorkflowTemplate coverage was limited.

Overview
Extends batch workloads (Jobs, CronJobs, Argo Workflows/CronWorkflows/Templates, KEDA ScaledJobs) across the Applications API/UI and workload logs/runs APIs, building on the redesigned app/workload scope model rather than restoring older layouts.

Backend: collectAppWorkloads now ingests batch kinds with appBatchSummary rollups (schedules, retained/active/failed runs, latest run phase), skips child Jobs/Workflows owned by launchers/templates, and classifies batch health separately from replica readiness. New GET .../runs returns retained run history with launchers, triggers, and pod counts. get_workload_logs / MCP get_workload_logs support Job and Workflow selectors; empty responses include emptyReason, guidance, and recovery commands when pods are gone after terminal completion. Issues classify Kubernetes RBAC forbidden messages (including Argo) and can group pod symptoms under the owning Workflow.

Shared UI (@skyhook-io/k8s-ui): Application list/detail use Runtime instead of Ready for job-class apps, batch signal chips for mixed apps, and optional renderOverviewIssues on Overview (replacing built-in synthetic “app issues”). Workload logs show Argo step metadata on pods and surface server empty-state messages/commands.

Docs: NOTES.md captures rebase assumptions; MCP docs note Workflow/Job in aggregated logs.

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

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 4 total unresolved issues (including 3 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 88bbf6e. Configure here.}