Grandiras/Ponente

Fork 0

Record the backup rehearsal, and that production has no remote #149

Merged

Grandiras merged 1 commit from issue-148-deploy-feedback-backups into main

2026-08-21 16:45:38 +00:00

Grandiras commented

2026-08-21 16:44:15 +00:00

Owner

Fixes #148.

Ran ./deploy/deploy.sh for production, which is what #148 asked for — the auto-update timer recreates the app container from the compose and env files the server already holds, so neither of 2.5.0's two changes could reach it through a tag.

"Report a problem" — deploy/.env already carried FEEDBACK_REPOSITORY and FEEDBACK_TOKEN; what was missing was the Feedback__* passthrough in the server's copy of the compose file. ponente-app now logs "Members can report a problem from the nav menu; reports are filed as issues" at startup instead of the not-configured line. The token has not been proven to hold write:issue rather than read:issue — the two are indistinguishable from outside without filing a real issue, and FeedbackService only checks that both settings are non-empty.

Backups — rehearsed on dev first, as backups.md says to, then production. Both timers are installed and both stacks have taken an archive that restored into a scratch Postgres and decrypted back to a matching sha256; restore.sh in verify mode passes on both. BACKUP_REMOTE is deliberately empty, so archives stay on the host: that covers a bad migration and not the machine being lost, and setting a remote wanted credentials scoped to a bucket rather than the one account-wide rclone remote to hand.

This commit is the documentation half. Three pages claimed production pushes offsite and that rootless podman, the systemd units and a PDS with real accounts were unrehearsed — all four are now untrue. The production run picked up actors/bb/did:plc:.../store.sqlite, a member's own repository, which the CI stand-in could not produce.

Fixes #148. Ran `./deploy/deploy.sh` for production, which is what #148 asked for — the auto-update timer recreates the app container from the compose and env files the server already holds, so neither of 2.5.0's two changes could reach it through a tag. **"Report a problem"** — `deploy/.env` already carried `FEEDBACK_REPOSITORY` and `FEEDBACK_TOKEN`; what was missing was the `Feedback__*` passthrough in the server's copy of the compose file. `ponente-app` now logs *"Members can report a problem from the nav menu; reports are filed as issues"* at startup instead of the not-configured line. The token has not been proven to hold `write:issue` rather than `read:issue` — the two are indistinguishable from outside without filing a real issue, and `FeedbackService` only checks that both settings are non-empty. **Backups** — rehearsed on dev first, as `backups.md` says to, then production. Both timers are installed and both stacks have taken an archive that restored into a scratch Postgres and decrypted back to a matching sha256; `restore.sh` in verify mode passes on both. `BACKUP_REMOTE` is deliberately empty, so archives stay on the host: that covers a bad migration and not the machine being lost, and setting a remote wanted credentials scoped to a bucket rather than the one account-wide rclone remote to hand. This commit is the documentation half. Three pages claimed production pushes offsite and that rootless podman, the systemd units and a PDS with real accounts were unrehearsed — all four are now untrue. The production run picked up `actors/bb/did:plc:.../store.sqlite`, a member's own repository, which the CI stand-in could not produce.

Grandiras added 1 commit

2026-08-21 16:44:15 +00:00

Record the backup rehearsal, and that production has no remote

CI / build (pull_request) Successful in 37s

Details

75b568a5ec

Ran deploy.sh for production so the 2.5.0 compose and env changes reached
the server: "Report a problem" is configured and the app now logs that the
nav row is there, and the backup timer is installed and has taken a
restore-verified archive. Rehearsed on the dev stack first, as backups.md
says to.

That moves three things off backups.md's "not rehearsed" list — rootless
podman, the systemd units under a real systemctl --user, and a PDS holding
an actual member repository, which the production run picked up as
actors/bb/did:plc:.../store.sqlite and the seeded stand-in could not
produce. BACKUP_REMOTE is deliberately still empty, so the archives are on
the disk they protect against; the three pages that claimed otherwise now
say so, with the reason.

Fixes #148

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

claude-bot commented

2026-08-21 16:44:19 +00:00

Collaborator

🤖 Reviewing this PR — follow along in the action run; the reply will link the full session transcript.

📜 Live transcript — updating every ~5 minutes while the task runs.

🤖 Reviewing this PR — follow along in [the action run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/375); the reply will link the full session transcript.  📜 [Live transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/pr-149/run-375.md) — updating every ~5 minutes while the task runs.

claude-reviewer approved these changes

2026-08-21 16:45:06 +00:00

claude-reviewer left a comment

✅ Verdict: approve — no blocking issues found.

Documentation-only PR, no code changes. It updates three pages (deploy/README.md, deploy/backups.md, docs/deployment.md) to reflect what was actually rehearsed in production and dev, and to be honest that BACKUP_REMOTE is currently unset.

Checked for internal consistency against the rest of the repo:

The deploy/README.md table row ("nightly, verified, on the host only — no remote set yet") matches the fuller explanation added to deploy/backups.md.
The new deploy/backups.md section correctly points readers to the existing "Turning it on" step 2 (rclone config + BACKUP_REMOTE) as the concrete way to close the gap — that step already exists in the file and matches the description given here.
The docs/deployment.md bullet edit threads the same caveat into the existing prose without contradicting anything else on the page (verification, encryption, WAL-mode PDS handling all still accurately described).
No new pages, paths, or services are introduced, so DocumentationTests's reachability/existence checks aren't implicated.
The stated reason for deliberately not setting a remote yet (the only rclone remote to hand is account-wide rather than bucket-scoped) is a sound, specific security rationale, consistent with how the rest of the deployment docs reason about credential scope.

No correctness or security issues found; this looks like an accurate, well-cross-referenced update of the deployment docs to match reality.

⏱ 0m 36s · 7 turns · tokens: 24.5k in / 2.1k out (+307.1k cache-read)
📜 Full session transcript

✅ **Verdict: approve** — no blocking issues found. Documentation-only PR, no code changes. It updates three pages (deploy/README.md, deploy/backups.md, docs/deployment.md) to reflect what was actually rehearsed in production and dev, and to be honest that `BACKUP_REMOTE` is currently unset. Checked for internal consistency against the rest of the repo: - The `deploy/README.md` table row ("nightly, verified, on the host only — no remote set yet") matches the fuller explanation added to `deploy/backups.md`. - The new `deploy/backups.md` section correctly points readers to the existing "Turning it on" step 2 (rclone config + `BACKUP_REMOTE`) as the concrete way to close the gap — that step already exists in the file and matches the description given here. - The `docs/deployment.md` bullet edit threads the same caveat into the existing prose without contradicting anything else on the page (verification, encryption, WAL-mode PDS handling all still accurately described). - No new pages, paths, or services are introduced, so `DocumentationTests`'s reachability/existence checks aren't implicated. - The stated reason for deliberately not setting a remote yet (the only rclone remote to hand is account-wide rather than bucket-scoped) is a sound, specific security rationale, consistent with how the rest of the deployment docs reason about credential scope. No correctness or security issues found; this looks like an accurate, well-cross-referenced update of the deployment docs to match reality. --- ⏱ 0m 36s · 7 turns · tokens: 24.5k in / 2.1k out (+307.1k cache-read) 📜 [Full session transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/pr-149/run-375.md)

Grandiras merged commit b7024784a0 into main

2026-08-21 16:45:38 +00:00

Grandiras referenced this pull request from a commit

2026-08-21 16:45:38 +00:00

Merge pull request 'Record the backup rehearsal, and that production has no remote' (#149) from issue-148-deploy-feedback-backups into main

No reviewers

No labels

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Grandiras/Ponente!149

No description provided.

Rows
Columns