recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues 1 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

journal(2): immich Q3.5 P4 decision — recipe-PR to add postgres backup (recipe backs up NO DB as published); validate vchord dump/restore empirically first

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
autonomic-bot
2026-05-29 23:44:47 +01:00
parent 9b2ce09a67
commit 7e2a5bc09c
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
machine-docs/JOURNAL-2.md
View File

@ -1161,3 +1161,38 @@ INTEGRATION PLAN (execute fresh):
for the build-trigger pipeline. SMOKE-FIRST: manually deploy gitea→create OAuth app→deploy drone wired
→confirm /healthz, before writing test code (nail the gitea CLI/API calls).
This is the heaviest Phase-2 integration; budget multiple iterations. Hold deploys if Adversary active.
---
## 2026-05-29T22:4x — immich Q3.5 P4 decision: recipe-PR (add postgres backup), not N/A
Resumed loop. Adversary checkpoint (REVIEW-2 `af94708`) confirms my own finding: immich's P4 restore
is RED and unsigned. Root-caused it directly on cc-ci:
- immich's `backupbot.backup` label sits ONLY on the `app` service, whose sole data volume `uploads`
is `backupbot.volumes.uploads=false` (excluded), and the two other excluded names (model-cache,
external_storage) aren't even on `app`. → app backs up nothing.
- the `database` (postgres, DB_USERNAME=postgres/DB_DATABASE_NAME=immich) service has NO backupbot
label and NO pg_dump hook. → the postgres DB is NOT backed up at all.
- No `abra.sh`, no top-level `configs:` section. So immich-as-published produces a backup containing
no restorable application data. My P4 ci_marker (postgres row) therefore cannot survive restore —
the test correctly detected a genuine, serious upstream deficiency (immich users get NO DB backup).
**WHY recipe-PR over §7.1 N/A sign-off:** immich is THE object-storage/large-volume D10 category
recipe — its entire purpose is storing user data. A P4-N/A here (unlike mailu's mail-relay N/A) would
be hollow: the data path is exactly what must be proven to survive. cc-ci exists to catch precisely
this class of bug; the recipe mirror+PR flow (§0b/§4.1) is the sanctioned mechanism, and the durable
fix was already filed as the immich Q3.5 deferral. So: author a recipe-PR adding a `database`-service
postgres backup (mirroring matrix-synapse's `/pg_backup.sh` config-mount + backupbot pre/restore
hooks), then `!testme`/`RECIPE=immich PR=<n>` proves P4 green on the fixed recipe.
**Reference pattern (matrix-synapse compose.yml):** db service `deploy.labels`:
`backupbot.backup.pre-hook="/pg_backup.sh backup"`, `backupbot.backup.volumes.postgres.path="backup.sql"`,
`backupbot.restore.post-hook="/pg_backup.sh restore"`; `configs: [{source: pg_backup, target:
/pg_backup.sh, mode: 0555}]`; top-level `configs.pg_backup.file=pg_backup.sh`. The script: backup =
`pg_dump -U $USER $DB | gzip > /var/lib/postgresql/data/backup.sql`; restore = drop+recreate+reimport.
**immich-specific risk to validate empirically BEFORE the PR:** the postgres image is VectorChord/
pgvecto.rs (custom extensions). A naive single-DB pg_dump|psql restore may choke on the vector
extension and on the live immich-server's held connections. So I'm deploying immich (install) now and
will test seed→dump→drop→restore→verify directly in the `database` container to pin down the exact
dump/restore commands (likely `pg_dumpall --clean --if-exists` and connection-termination on restore)
that round-trip the ci_marker, then bake the proven commands into pg_backup.sh. No "should work".