Commit Graph

2 Commits

Author SHA1 Message Date
b0txec cb7e9aa06b Record the Faktiskā blank-temperature fix and correct a runbook bug
CI / backend (push) Successful in 1m3s
CI / frontend (push) Successful in 40s
Documents release a6b2b84 (the queryLatestTemperatures fix and the user's
CSS polish pass) in the changelog and README status line. Also fixes a real
bug in VPS_RELEASE_RUNBOOK.md's own checksum step, found by actually running
it for this release: it generated the .sha256 file against a full local
path rather than a bare filename, which fails verification on the VPS since
that path doesn't exist there.
2026-08-25 17:19:17 +03:00
b0txec 39478bde1d Add a literal, runnable VPS release runbook
CI / backend (push) Successful in 1m9s
CI / frontend (push) Successful in 1m0s
VPS_STAGING_PLAN.md describes the release process at a policy level; the
changelog table narrates what happened after each release. Neither is a
step-by-step "how" a person (or Guntis) could actually follow without
already knowing the process from having run it. This is that document --
copy-pasteable commands, in order, parameterized by commit SHA.

Writing it surfaced a real regression: earlier releases (through ef64895)
retained the release tarball under /srv/weathertool/releases/<sha>/ and
backed up .env.staging before every edit; tonight's releases (0be325f,
9bab93d, 001b014) did neither -- I'd been deleting the transfer copy from
/tmp after each deploy and sed-ing .env.staging directly with no backup.
Practical cost: rolling back to any of tonight's releases would have meant
rebuilding from git history and re-transferring, instead of just re-pointing
.env.staging at an already-present image. Closed the gap for the current
live release (001b014) retroactively -- exported it directly on the VPS
(checksum matches the exact bytes shipped tonight, confirming no drift) and
backed up the current .env.staging -- and the runbook restores both habits
going forward.
2026-08-25 11:51:23 +03:00