Use Kubernetes CronJob for cron-based TaskSpawners

[axon-agent]

Summary

• Replace custom cron polling logic in TaskSpawner with native Kubernetes CronJob scheduling
• When spec.when.cron is set, the controller now creates a CronJob (not a Deployment) that runs the spawner in one-shot mode on the cron schedule itself
• This eliminates the confusing pollInterval + cron schedule overlap (closes Re implement TaskSpawnwer's cron #430, related to having pollinterval and cron doesn't make sense #138)
• Add --one-shot flag to the spawner binary for single-cycle execution used by CronJob pods
• Add status.cronJobName field to track the CronJob resource
• Add tests for CronJob building, schedule updates, suspend toggle, and stale resource cleanup
• Clean up stale Deployment/CronJob when switching between polling and cron modes to prevent duplicate task spawning

Test plan

• make verify passes
• make test passes (all unit tests including new stale resource cleanup tests)
• CI e2e tests pass
• Manual testing: create a TaskSpawner with when.cron and verify CronJob is created
• Manual testing: verify suspend/resume toggles CronJob .spec.suspend
• Manual testing: verify schedule updates propagate to CronJob
• Manual testing: switch a TaskSpawner from polling to cron and verify old Deployment is cleaned up

🤖 Generated with Claude Code

[cubic-dev-ai]

1 issue found across 10 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/taskspawner_controller.go">

<violation number="1" location="internal/controller/taskspawner_controller.go:91">
P2: Cron-based reconciliation doesn’t clean up an existing Deployment when a TaskSpawner is switched from polling to cron, so the old Deployment keeps running and can spawn duplicate tasks. Add a cleanup step before creating/updating the CronJob.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

2 issues found across 13 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/taskspawner_controller.go">

<violation number="1" location="internal/controller/taskspawner_controller.go:259">
P2: When switching between cron and polling modes, stale status fields are not cleared. `reconcileCronJob` sets `CronJobName` but doesn't clear `DeploymentName`, and vice versa. After a mode switch, the status will reference a deleted resource, which could confuse users and tooling.</violation>

<violation number="2" location="internal/controller/taskspawner_controller.go:399">
P0: Bug: `reconcileCronJob` never resolves the workspace or detects GitHub App auth, and `BuildCronJob` hardcodes `nil`/`false` for these. CronJob-based TaskSpawners that reference a workspace will be missing `--github-owner`, `--github-repo` args, and all GitHub auth (PAT env var or token-refresher sidecar), causing them to fail at runtime.

`reconcileCronJob` needs workspace resolution logic (same as `reconcileDeployment`), `BuildCronJob` needs to accept `workspace` and `isGitHubApp` parameters, and the call sites in `createCronJob`/`updateCronJob` need to pass them through.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}