Skip to content

feat: per-project publish gate for dashboard snapshot - #52

Merged
rssrn merged 2 commits into
mainfrom
feat/publish-gate
Jul 24, 2026
Merged

feat: per-project publish gate for dashboard snapshot#52
rssrn merged 2 commits into
mainfrom
feat/publish-gate

Conversation

@labro-bot

@labro-bot labro-bot Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds an opt-in publish flag to ProjectConfig so the dashboard snapshot only includes runs from projects that explicitly enable publishing. Default is False — new projects and new deployments contribute nothing to the public dashboard until opted in.

Fixes #51

Changes

  • config/schema.py: publish: bool = False field on ProjectConfig
  • cli.py: _cmd_publish_db filters snapshot by published projects (deletes non-published rows from runs, items_touched, and projects in the snapshot copy after VACUUM INTO)
  • tests/test_publish_db.py: 5 new tests covering no-publish, mixed, all-publish, items_touched filtering, and manifest row_count accuracy

Config note

The three current public projects need publish = true in labro-rssrn/labro.toml to keep appearing on the dashboard.

Labro Bot and others added 2 commits July 21, 2026 09:22
Add publish: bool = False to ProjectConfig so the dashboard snapshot
only includes runs from explicitly opted-in projects. Fails safe —
new projects publish nothing until opted in.

- Filter snapshot rows by published projects after VACUUM INTO
- Upsert only published projects to the projects table
- 5 new tests covering all filtering scenarios

Fixes #51
The publish gate filtered runs/items_touched/projects but left the
project_locks table untouched, so an unpublished project's name shipped
in the snapshot as a live row whenever a lock existed (transient, during
an in-flight run or a stale lock). Filter project_locks alongside the
other tables — this is the substantive leak this commit closes.

Also VACUUM the snapshot after the DELETEs. On the SQLite builds we ship
(Debian bookworm and the dev interpreter) secure_delete is compiled in
and defaults ON, so freed-page residue is already zeroed there; the
VACUUM is defensive hardening that makes the no-residue guarantee hold
regardless of the build's secure_delete setting, and it corrects the
reported size_bytes. Fold the row-count read into the same connection
instead of reopening the snapshot.

Adds a byte-level regression test asserting no unpublished project name
or free-text survives in the raw snapshot bytes.
@rssrn

rssrn commented Jul 24, 2026

Copy link
Copy Markdown
Owner

Reviewed and verified by driving the real labro publish-db CLI. Follow-up commit 69e7b4f adds the substantive fix — filtering the previously-untouched project_locks table (a project name leaked there as a live row) — plus a VACUUM on the snapshot as build-independent residue hardening, and a byte-level regression test. Verification note: the free-page residue path is already closed on our deployed SQLite builds (Debian bookworm + dev), which ship with SECURE_DELETE compiled in, so the VACUUM is defensive rather than a critical fix. Config side (labro-rssrn) already has publish = true on all 6 public-repo projects, so the dashboard's contents are preserved once the gated image ships.

@rssrn
rssrn merged commit ae770df into main Jul 24, 2026
1 check passed
@rssrn
rssrn deleted the feat/publish-gate branch August 3, 2026 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Sanitize published dashboard DB: full runs table (agent free-text + repo/issue refs) is exposed to a public bucket with no redaction or per-repo gating

2 participants