9375e3d4ee
Adds an opt-in goroutine that polls GHCR every 5 minutes for digest changes on each workspace-template-*:latest tag and invokes the same refresh logic /admin/workspace-images/refresh exposes. With this, the chain from "merge runtime PR" to "containers running new code" is fully hands-off — no operator step between auto-tag → publish-runtime → cascade → template image rebuild → host pull + recreate. Opt-in via IMAGE_AUTO_REFRESH=true. SaaS deploys whose pipeline already pulls every release should leave it off (would be redundant work); self-hosters get true zero-touch. Why a refactor of admin_workspace_images.go is in this PR: The HTTP handler held all the refresh logic inline. To share it with the new watcher without HTTP loopback, extracted WorkspaceImageService with a Refresh(ctx, runtimes, recreate) (RefreshResult, error) shape. HTTP handler is now a thin wrapper; behavior is preserved (same JSON response, same 500-on-list-failure, same per-runtime soft-fail). Watcher design notes: - Last-observed digest tracked in memory (not persisted). On boot the first observation per runtime is seed-only — no spurious refresh fires on every restart. - On Refresh error, the seen digest rolls back so the next tick retries. Without this rollback a transient Docker glitch would convince the watcher the work was done. - Per-runtime fetch errors don't block other runtimes (one template's brief 500 doesn't pause the others). - digestFetcher injection seam in tick() lets unit tests cover all bookkeeping branches without standing up an httptest GHCR server. Verified live: probed GHCR's /token + manifest HEAD against workspace-template-claude-code; got HTTP 200 + a real Docker-Content-Digest. Same calls the watcher makes. Co-authored-by: Hongming Wang <hongmingwangalt@gmail.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| adapters | ||
| adr | ||
| agent-runtime | ||
| api-protocol | ||
| architecture | ||
| assets | ||
| blog | ||
| development | ||
| devrel/demos/tool-trace-platform-instructions | ||
| engineering | ||
| frontend | ||
| guides | ||
| incidents | ||
| infra | ||
| integrations | ||
| pages/api | ||
| plugins | ||
| tutorials | ||
| .gitignore | ||
| api-reference.md | ||
| ecosystem-watch.md | ||
| glossary.md | ||
| index.md | ||
| internal-content-policy.md | ||
| quickstart.md | ||
| README.md | ||
| workspace-runtime-package.md | ||
docs/
This directory serves two purposes:
- Markdown content — everything under
architecture/,agent-runtime/,api-protocol/,development/,frontend/,plugins/,product/, etc. This is what agents and humans read. - VitePress site —
.vitepress/config.ts,package.json,package-lock.json. These drive the rendered documentation site.
Local preview
cd docs
npm install
npm run dev # preview on http://localhost:5173
npm run build # static build to docs/.vitepress/dist/
Conventions
- New top-level docs must be linked from
PLAN.md,README.md, andCLAUDE.md— otherwise agents can't find them (see.claude/memoryfeedback_cross_reference_docs.md). edit-history/YYYY-MM-DD.mdis append-only log of significant changes; don't rewrite history.archive/holds one-shot analyses and retired docs — kept for context but not maintained.
Why site tooling lives here (not in docs-site/)
VitePress expects its config at <root>/.vitepress/config.ts where <root> is also the content directory. Splitting tooling into a sibling docs-site/ would require a non-trivial srcDir shim and break relative links in .vitepress/config.ts. Keeping both together is the pragmatic choice; this README is the tradeoff ledger.