feat: workspace volumes for prod

[knechtionscoding]

Equivalent to: kelos-dev#921 but for our prod branhc

What type of PR is this?

/kind feature

What this PR does / why we need it:

Adds a new optional spec.volumes field to the Workspace CRD, allowing users to mount additional volumes (PVCs, ConfigMaps, Secrets, EmptyDirs) into the agent container.

This enables use cases like:

• Mounting a PVC with pre-populated node_modules or other dependency caches
• Attaching ReadOnlyMany volumes with large shared datasets or model weights
• Injecting configuration via ConfigMap or Secret volumes

User-defined volumes are supplementary — the workspace EmptyDir is unchanged and the repo is always freshly cloned for isolation.

Changes:

• api/v1alpha1/workspace_types.go: New WorkspaceVolume type and Volumes field on WorkspaceSpec
• internal/controller/job_builder.go: Appends user volumes to pod spec and mounts them into the agent container
• internal/controller/job_builder_test.go: 4 new tests (single PVC, multiple volumes, volumes + plugins, empty volumes backward compat)
• examples/12-workspace-with-volumes/: Example workspace with a PVC volume
• Generated: deepcopy, CRD manifests, client code via make update

Which issue(s) this PR is related to:

Part of kelos-dev#774

This is the first of two PRs for kelos-dev#774. The second PR will add spec.setup (init containers) which will also receive these volume mounts.

Special notes for your reviewer:

• WorkspaceVolume.Source uses the Kubernetes-native corev1.VolumeSource type directly, so no custom volume abstraction is needed. Restricting volume source types (e.g. disallowing hostPath) is left to cluster admission policy, consistent with how most operators handle this.
• Both fields are optional with zero-value defaults — existing Workspace resources work identically with no migration.

Does this PR introduce a user-facing change?

Add `spec.volumes` field to Workspace CRD for mounting additional volumes (PVCs, ConfigMaps, Secrets) into the agent container.

---

Summary by cubic

Adds an optional spec.volumes to the Workspace CRD so users can mount extra volumes (PVC, ConfigMap, Secret, EmptyDir) into the agent container. The default workspace EmptyDir and fresh clone remain unchanged; part of kelos-dev#774.

• New Features

  • CRD: add WorkspaceVolume and spec.volumes using corev1.VolumeSource; enforce unique names and reserve "workspace" and "kelos-plugin".
  • Controller: append user volumes to the pod and mount them in the agent container.
  • Tests: cover single/multiple volumes, with plugins, and an explicit empty list for backward compatibility.
  • Examples: add examples/12-workspace-with-volumes/ and examples/15-workspace-with-setup/.
  • Manifests: regenerate CRD YAML in chart and install bundles; update deepcopy.

• Bug Fixes

  • CLI/Helm tests: match only real :latest image refs using a regex to avoid false positives from CRD descriptions.

^{Written for commit 9021205. Summary will update on new commits.}

[anomalogravity]

Risk Assessment: Low

Summary: Adds an optional volumes field to the WorkspaceSpec CRD, allowing users to mount supplementary Kubernetes volumes into agent containers (PVCs, ConfigMaps, Secrets, EmptyDir, etc.).

Factors supporting Low risk:

• Additive, backwards-compatible change — Volumes is an optional field; existing Workspace resources are unaffected
• Small core logic change — ~15 lines added to job_builder.go that iterate over workspace volumes and append them to pod volumes/mounts
• Well-tested — 4 comprehensive new tests covering: single volume (PVC), multiple volumes (PVC + ConfigMap), volumes with plugins, and empty volume list
• Large diff is auto-generated — the 4,200+ line bulk is kubebuilder-generated CRD OpenAPI YAML for corev1.VolumeSource; actual logic changes are small
• Test quality improvement included — regex fix to imageLatestRe prevents false positives in existing :latest tag tests caused by CRD description strings
• No critical path touched — no changes to authentication, public API, database connectors, or ML algorithms
• This is a kelos operator repo — separate from the core Anomalo platform

Minor considerations (not escalating risk):

• Allows mounting arbitrary volume types including Secrets — this is intentional and consistent with the operator's design; users with Workspace CR create permissions already have cluster access
• No explicit uniqueness validation on volume names, but Kubernetes itself will reject duplicate volume names at pod creation time

[anomalogravity]

Auto-approved: PR assessed as low risk by Gravity.

[greptile-apps]

Greptile Summary

This PR ports workspace volume support from the main branch to prod, allowing users to mount additional Kubernetes volumes (PVCs, ConfigMaps, Secrets, etc.) into the agent container via a new WorkspaceVolume type in WorkspaceSpec.Volumes. The implementation in job_builder.go is correct and well-tested, but the API type is missing CRD-level guardrails that could cause silent pod scheduling failures.

• P1 — missing uniqueness and reserved-name validation on Volumes: Unlike Remotes, the Volumes field has no CEL XValidation rule enforcing unique names or preventing use of reserved names ("workspace", "kelos-plugin"). Duplicate or reserved names produce invalid pod.spec.volumes that Kubernetes rejects at pod creation, leaving users with a cryptic error instead of an early API validation message.

Confidence Score: 4/5

Safe to merge after adding CEL uniqueness/reserved-name validation on the Volumes field to match the existing Remotes pattern.

One P1 finding: the Volumes field lacks the same CEL uniqueness and reserved-name guards that Remotes has, meaning a misconfigured workspace spec can silently produce an unschedulable Job. The P2 (missing absolute-path pattern on MountPath) is advisory. Core implementation and tests are solid.

api/v1alpha1/workspace_types.go — missing XValidation markers on the Volumes field.

Important Files Changed

Filename	Overview
api/v1alpha1/workspace_types.go	Adds WorkspaceVolume type and Volumes field to WorkspaceSpec; missing CEL uniqueness/reserved-name validation on the new Volumes field and missing absolute-path pattern on MountPath.
internal/controller/job_builder.go	Appends user-defined workspace volumes and mounts to the agent container after the built-in workspace volume; implementation is correct and well-placed.
internal/controller/job_builder_test.go	Adds four thorough tests covering single volume, multiple volumes, volumes with plugins, and empty volumes list; good coverage of the new feature.
api/v1alpha1/zz_generated.deepcopy.go	Auto-generated deep copy for WorkspaceVolume correctly delegates to VolumeSource.DeepCopyInto to handle nested pointers.
examples/14-workspace-with-volumes/workspace.yaml	New example demonstrating a PVC-backed npm-cache volume; readOnly: true is set at both the WorkspaceVolume and PVC source levels, which is redundant but not incorrect.
internal/manifests/charts/kelos/templates/crds/workspace-crd.yaml	CRD updated to include the full WorkspaceVolume schema with the complete Kubernetes VolumeSource union; generated correctly.
internal/manifests/install-crd.yaml	Install CRD manifest updated in sync with the Helm chart CRD; no issues.
internal/slack/handler.go	Included as part of the upstream merge; no functional changes to the workspace volumes feature.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[WorkspaceSpec.Volumes] -->|loop over wv| B[append corev1.Volume to pod spec]
    B --> C[append VolumeMount to agent container]
    D[Built-in workspace EmptyDir] -->|added first| B
    E{agentConfig plugins/skills?} -->|yes| F[append kelos-plugin EmptyDir]
    F --> B
    G[No uniqueness/reserved-name validation] -.->|duplicate or reserved name| H[Kubernetes rejects pod spec at creation]
    B --> I[Job created successfully]
    I -->|Kubernetes validates pod spec| H
    I -->|valid names| J[Pod scheduled]

Loading

_{Reviews (1): Last reviewed commit: "feat: workspace volumes for prod" | Re-trigger Greptile}