Skip to content

feat(nextcloud): allow suspending the cron CronJob via values - #881

Open
marekjagielski wants to merge 1 commit into
nextcloud:mainfrom
marekjagielski:feat/cronjob-suspend
Open

feat(nextcloud): allow suspending the cron CronJob via values#881
marekjagielski wants to merge 1 commit into
nextcloud:mainfrom
marekjagielski:feat/cronjob-suspend

Conversation

@marekjagielski

@marekjagielski marekjagielski commented Aug 24, 2026

Copy link
Copy Markdown

Description of the change

Renders spec.suspend on the cron CronJob unconditionally (defaulting to false), and exposes it as cronjob.cronjob.suspend.

Benefits

The template currently renders no spec.suspend at all, so the field has no desired value in the manifest. Anything that reconciles the chart's output — ArgoCD, Flux, helm diff — has nothing to compare against, and under server-side apply a kubectl patch ... suspend=true takes ownership of the field and survives every subsequent sync, while the release keeps reporting as in-sync.

That is not hypothetical. We had nextcloud-cron suspended by hand during a debugging session and left that way for days. ArgoCD reconciled that very object repeatedly across the period and left the suspension in place — correctly, since it did not own the field. In that window Nextcloud ran no file scans, no trashbin/version expiry, no notification delivery, no federated sync and no app-update checks, and nothing surfaced it. managedFields showed spec.suspend owned by kubectl-patch, never by argocd-controller.

Rendering the field always puts it back under the chart's ownership, so a manual patch is reverted on the next sync instead of silently persisting. It also makes suspending the job a first-class values option rather than something you reach around the chart to do.

Possible drawbacks

None that I can find. false is already the CronJob API default, so behaviour is unchanged for every existing release — the only difference is that a previously-omitted field now renders as an explicit false. For users who deliberately suspend the job out-of-band today, that manual patch will now be reverted on the next chart apply; setting cronjob.cronjob.suspend: true is the supported replacement, and arguably the point of the change.

Applicable issues

None open that I could find — happy to file one first if you'd prefer that order.

Additional information

Verified against charts/nextcloud:

  • helm lint . — 1 chart linted, 0 failed
  • helm template . with cronjob.enabled=true cronjob.type=cronjobsuspend: false
  • same with --set cronjob.cronjob.suspend=truesuspend: true
  • cronjob.type=sidecar renders no CronJob, unaffected
  • documented in values.yaml and the README values table
  • Chart.yaml bumped 9.2.6 → 9.3.0 (minor: adds a value, no breaking change)

Checklist

The CronJob template renders no `spec.suspend`, so the field has no
desired value in the manifest. Anything that reconciles the chart's
output — ArgoCD, Flux, `helm diff` — has nothing to compare against, and
a `kubectl patch ... suspend=true` therefore survives every subsequent
sync while the release keeps reporting as in-sync.

That is not hypothetical: we had `nextcloud-cron` suspended by hand
during a debugging session and left that way for 40 days. ArgoCD
reconciled the object repeatedly over that period and left the
suspension in place, because server-side apply correctly treats
`spec.suspend` as owned by the client that set it. No file scans, no
trashbin/version expiry, no notification delivery and no federated sync
ran in that window, and nothing surfaced it.

Render `suspend` unconditionally, defaulting to false, so the field is
always present and always owned by whatever applies the chart. This also
makes suspending the job a first-class values option rather than
something you have to reach around the chart to do.

Default behaviour is unchanged: `suspend: false` is the CronJob API
default, so existing releases render an explicit false where the field
was previously omitted.

Signed-off-by: Marek Jagielski <marek.jagielski@protonmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant