2 Commits

Include renames

Author	SHA1	Message	Date
menzeljandClaude Opus 5	9a357d2b92	Schedule backups in local time instead of UTC (0.66.0) ... Schedule times were UTC, so a nightly 03:00 backup had to be entered as 01:00 or 02:00 depending on the season, and moved by an hour twice a year. Each schedule now has an IANA time zone, preset in the form to the browser's (e.g. Europe/Berlin), and its hour/minute/weekday are wall-clock time there. compute_next_run builds each candidate day from its date in that zone rather than adding 24 hours, so the time stays put across daylight saving changes; a time skipped by the spring change runs an hour later that day. next_run is still stored as naive UTC. - Existing schedules default to UTC and keep their run times until edited. - The API validates the zone and hour/minute/weekday ranges (400) instead of silently wrapping them. - tzdata is a dependency: the slim base image has no system tz database. Tests cover Berlin winter and summer time, both 2026 change days, the skipped hour, a weekly run across the UTC date line, hourly at a +5:30 offset, the UTC fallback and the API checks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-18 12:50:46 +02:00
menzeljandClaude Opus 5	8a0d673798	Back up several stacks, or all of them, from one schedule (0.65.0) ... A schedule covered exactly one stack, so backing up a host meant one schedule per stack, each edited separately, and new stacks were only backed up once someone remembered to add a schedule. A schedule now takes a list of stacks, or all_stacks, which includes stacks added later. They are backed up one after another, each with its own file, upload, retention and status, so one failing stack does not cost the others their backup: - stack_status records each stack's result; last_status summarises ("error: 2 of 5 stacks - a: ...; c: ...") and one notification per run names the stacks with a problem. The dashboard names them too and shows an incomplete backup as a warning rather than an error. - A busy stack (deploy, update) is retried after the others, up to three times two minutes apart, replacing the 10-minute postponement of the whole schedule. - Run now starts the run in the background (202) instead of holding the request, which a multi-stack run would outlast; the list reports running and polls, and the row toasts the outcome. A schedule never runs twice at once. - Settings: "All stacks" or a checklist with select all/none; stacks can be changed when editing; deleted stacks stay listed to be unticked. Schedules from before keep working without a data migration: stack_ids, all_stacks and stack_status are added with defaults on startup and a row with only stack_id reads as that one stack. The API still accepts stack_id and reports it for single-stack schedules. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-18 12:44:28 +02:00