Point the monthly restore drill at Prod (go-live #87)
All checks were successful
CD / Build and push images (push) Successful in 1m7s
CD / Deploy to Test (push) Successful in 9s
CD / Smoke tests against Test (push) Successful in 1m17s
CD / Promote to Int (push) Successful in 11s
CI / Lint, typecheck, test (push) Successful in 4m9s
CI / Build container images (push) Has been skipped
CI / Auth e2e pack (push) Successful in 5m38s
CI / Import/export fidelity gate (push) Successful in 48s
Restore drill / Restore the latest backup into a scratch stack (push) Successful in 21s

The runner on ONE holds dorfteich-prod_backups; since go-live the drill
that proves a backup restores should target the live instance, not Test.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwZ4jR4KFAPvpjWevfUGX1
This commit is contained in:
Claude Fable 5 2026-07-12 19:58:19 +02:00
parent baebd79cc8
commit a35f7135bf

View File

@ -1,8 +1,11 @@
# Monthly restore drill (ADR 0015, issue #87): restores the latest backup
# set of the drilled stage into a scratch environment on the runner's Docker
# daemon (the stage host), verifies it, and logs the outcome as a comment on
# the pinned "Restore drills" issue. Pre-go-live the drilled stage is Test;
# switch DRILL_SOURCE_VOLUME to the Prod backups volume at go-live (#89).
# the pinned "Restore drills" issue. Since go-live (2026-07-12, #89) the
# drilled stage is Prod; the runner on ONE holds the dorfteich-prod_backups
# volume. TAG stays `test` on purpose: it only selects the drill-harness
# images (backup + api) that perform and verify the restore, and a forward
# schema restores a Prod set fine — it is not a claim about the Prod release.
name: Restore drill
@ -18,7 +21,7 @@ on:
env:
IMAGE_BASE: gitea.101010.cloud/stwaidele/dorfteich
DRILL_SOURCE_VOLUME: dorfteich-test_backups
DRILL_SOURCE_VOLUME: dorfteich-prod_backups
DRILL_LOG_ISSUE: '98'
jobs: