* feat: add cron scheduling mode for image update checks
Adds a cron scheduling mode alongside the existing fixed-interval
dropdown in Settings > Automation > Image update checks. Users can
now set a 5-field cron expression (e.g. "0 3 * * 1") for precise
time-of-day scheduling of registry polls.
- Backend: ImageUpdateService gains mode/cronExpression fields and
cron-based nextDelayMs() using the existing cron-parser dependency.
PUT /api/image-updates/interval extended with transactional writes
and server-authoritative cron validation matching the Scheduled
Operations contract. Nicknames like @daily are supported.
- Frontend: UpdatesSection gains a SegmentedControl toggle and cron
text input with cronstrue-powered live description. The frontend
does advisory validation only; backend 400s are surfaced inline.
SettingsPrimaryButton used for explicit "Save schedule" action.
- No cron jitter (the user chose a specific time). Interval mode
keeps existing ±10% jitter.
- Tests: 15 new backend tests covering valid cron, invalid cron,
6-field rejection, nickname support, backward compat, runtime
fallback, and transactional writes.
- Docs: auto-update-policies.mdx, alerts-notifications.mdx, and
openapi.yaml updated with new scheduling mode.
* fix: add mode and cronExpression to UpdatesSection test fixtures
The existing tests failed because the mock status object was missing
the new required fields (mode, cronExpression) added with cron
scheduling support. Without them, status.mode was undefined, causing
uiMode to never match 'interval' and the Select combobox to not render.
* fix: prevent SegmentedControl from stretching full-width in SettingsField
The flex-col container defaults items to align-self: stretch, making the
Interval/Cron toggle bar span the full card width. Add self-start so it
sizes to its content.
* feat: make image-update check cadence configurable and visible
The background image-update scanner polled registries on a hardcoded
6-hour interval, with no way to see when it last ran or when the next
run was due. Operators testing updates read this as auto-update being
unreliable: a manual update checks the registry immediately and applies,
so the slow background scan rarely raised the "update available"
notification before the stack was already current.
Backend:
- ImageUpdateService reads image_update_check_interval_minutes (15-1440,
default 120) and drives a single generation-guarded self-rescheduling
timer with 10% per-run jitter so fleet nodes do not poll in lockstep.
restartPolling() applies a new interval live, with no restart, and
cannot leave a duplicate timer when a save lands mid-scan.
- GET /api/image-updates/status now returns checking, intervalMinutes,
lastCheckedAt, nextCheckAt, and the manual-cooldown fields. New
admin-only PUT /api/image-updates/interval persists the setting and
reschedules.
Frontend:
- New Settings > Automation > Image update checks section to choose the
interval (read-only for non-admins; admin enforced on the backend).
- The Auto-Update readiness view shows last-checked, next-check, and a
ticking manual-recheck cooldown, and the copy distinguishes registry
detection from scheduled auto-update execution.
Adds backend unit and route tests and frontend component tests, and
updates the auto-update documentation.
* fix: drop stale image-update status response in the readiness strip
loadCadence() ran on mount and again after a Recheck with no request
token, so a slow initial /image-updates/status response could resolve
after the recheck-triggered one and overwrite the fresh cooldown with
stale data, or set state after the view unmounted. Guard setCadence with
a monotonic token mirroring loadReadiness, and bump it on unmount. Adds a
regression test for the out-of-order resolution.
Anso