fix(release): keep large snapshots attached and low impact
Managed validation / ${{ inputs.profile || 'full' }} (pull_request) Failing after 1m35s
GeoIntel release gates / Compile, test, contracts and builds (pull_request) Failing after 1m43s
GeoIntel release gates / Python and npm vulnerability policy (pull_request) Failing after 32s
GeoIntel release gates / Production AI image, SBOM and container scan (pull_request) Failing after 31s
GeoIntel release gates / Deploy exact gated revision to Unraid (pull_request) Skipped

This commit is contained in:
Jens
2026-08-30 10:09:26 +02:00
parent f77f6f2d93
commit fd58cb2378
4 changed files with 55 additions and 6 deletions
+9
View File
@@ -80,6 +80,15 @@ Create an immutable byte-complete backup. Initial storage/model copy and
verification can be I/O-heavy; subsequent backups deduplicate unchanged bytes
against the newest verified prior snapshot:
The gated Unraid job keeps its controller request attached for up to twelve
hours because an initial snapshot can exceed 100 GiB. Release runs for the same
branch queue instead of cancelling an in-flight deploy. Snapshot copying and
checksum verification use the lowest available best-effort CPU and I/O
priority (`nice` and `ionice`) while the deploy lock prevents overlap. If an
operator manually cancels the caller, inspect the controller state and
`/mnt/user/appdata/gitea-deploy-runners/deploy.lock` before retrying; never
assume that cancelling the HTTP client terminated the server-side operation.
```bash
bash scripts/backup_release_state.sh \
--container geointel \