[infra] vendor demo PDF seed content + reproducible seed script (incl. PDFs in repo under seed/office/) #56

New issue

Closed

opened 2026-05-01 18:36:20 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-01 18:36:20 +00:00

Owner

Summary

The demo expects a set of marketing/product PDFs to be openable from the Office island for any registered context. Today these files are seeded ad-hoc by an operator running scp + cp across ~/hero/var/hero_foundry/webdav/<context>/Office/. We need to formalise this so:

Demo content is reproducible across deploys (next time someone re-provisions herodemo, they don't have to remember which files go where).
The content lives in version control somewhere accessible, not on a single workstation.
A script seeds them per-context, idempotently.

Today's seed (manually executed 2026-05-01)

A set of demo PDFs was seeded into all 9 registered contexts on herodemo. The exact command shape (raw material for the 50_demo_content_seed.sh script in hero_demo#55):

# On VM (root):
WEBDAV=~/hero/var/hero_foundry/webdav
CONTEXTS='root default geomind incubaid my_context our_context threefold your_context hero_osis'
for ctx in $CONTEXTS; do
    mkdir -p $WEBDAV/$ctx/Office
    cp /tmp/seed_pdfs/*.pdf $WEBDAV/$ctx/Office/
done
chown -R driver:driver $WEBDAV

Verified: 9 contexts × 7 PDFs = 63 files, ~42M per context.

Proposal

Pick a private or restricted-access location for the seed content. The current demo PDFs include pre-release / NDA-classed material and must NOT be vendored into a public-or-org-readable repo. Options:
- A separate private repo in the org (access-controlled)
- An object store (S3-compatible, signed URLs)
- Forgejo packages with restricted visibility
Add scripts/verify/50_demo_content_seed.sh per hero_demo#55 — fetches from the chosen private location, drops into per-context webdav, idempotent on sha256.
Per-context content vs shared content: today every context gets the same set. Long-term we may want context-specific demo data. For now, shared is fine.
Future content types: same pattern works for Photos/, Videos/, Documents/. The seeding script in #55 is generalised on the source dir, so adding more content types is mechanical.

Out of scope

Seeding hero_osis_business contacts / deals / companies (different mechanism — OTOML files; needs its own per-context content set + import path).
Seeding hero_books libraries (already handled by libraries.txt).
Seeding hero_collab channels / messages (different mechanism — RPC channel.create etc.).

Each of those is its own seed pipeline. Files-on-disk content is the simplest of the four.

Cross-refs

hero_demo#55 — post-deploy verification scripts (this issue's content seed is item E)
DEPLOYMENT.md §6 already mentions "Seed sample office content into the foundry webdav" — formalising the content + script makes that step real.

## Summary The demo expects a set of marketing/product PDFs to be openable from the **Office** island for any registered context. Today these files are seeded ad-hoc by an operator running scp + cp across `~/hero/var/hero_foundry/webdav/<context>/Office/`. We need to formalise this so: - Demo content is reproducible across deploys (next time someone re-provisions herodemo, they don't have to remember which files go where). - The content lives in version control somewhere accessible, not on a single workstation. - A script seeds them per-context, idempotently. ## Today's seed (manually executed 2026-05-01) A set of demo PDFs was seeded into all 9 registered contexts on herodemo. The exact command shape (raw material for the `50_demo_content_seed.sh` script in [hero_demo#55](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/55)): ```bash # On VM (root): WEBDAV=~/hero/var/hero_foundry/webdav CONTEXTS='root default geomind incubaid my_context our_context threefold your_context hero_osis' for ctx in $CONTEXTS; do mkdir -p $WEBDAV/$ctx/Office cp /tmp/seed_pdfs/*.pdf $WEBDAV/$ctx/Office/ done chown -R driver:driver $WEBDAV ``` Verified: 9 contexts × 7 PDFs = 63 files, ~42M per context. ## Proposal 1. **Pick a private or restricted-access location for the seed content.** The current demo PDFs include pre-release / NDA-classed material and must NOT be vendored into a public-or-org-readable repo. Options: - A separate private repo in the org (access-controlled) - An object store (S3-compatible, signed URLs) - Forgejo packages with restricted visibility 2. **Add `scripts/verify/50_demo_content_seed.sh`** per [hero_demo#55](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/55) — fetches from the chosen private location, drops into per-context webdav, idempotent on sha256. 3. **Per-context content vs shared content**: today every context gets the same set. Long-term we may want context-specific demo data. For now, shared is fine. 4. **Future content types**: same pattern works for `Photos/`, `Videos/`, `Documents/`. The seeding script in #55 is generalised on the source dir, so adding more content types is mechanical. ## Out of scope - Seeding hero_osis_business contacts / deals / companies (different mechanism — OTOML files; needs its own per-context content set + import path). - Seeding hero_books libraries (already handled by `libraries.txt`). - Seeding hero_collab channels / messages (different mechanism — RPC `channel.create` etc.). Each of those is its own seed pipeline. Files-on-disk content is the simplest of the four. ## Cross-refs - [hero_demo#55](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/55) — post-deploy verification scripts (this issue's content seed is item E) - DEPLOYMENT.md §6 already mentions "Seed sample office content into the foundry webdav" — formalising the content + script makes that step real.

mik-tf closed this issue

2026-05-01 19:34:56 +00:00

No labels

No milestone

No project

No assignees

1 participant

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

lhumina_code/hero_demo#56

No description provided.

Rows
Columns