23 Commits

Author	SHA1	Message	Date
joakimp	668592da0d	Base: SSH ControlMaster default on a writable socket path ... Devboxes typically mount ~/.ssh from the host read-only (security: keys readable, but agents can't tamper with config / known_hosts / authorized_keys / plant a malicious ProxyCommand). OpenSSH's default ControlPath is ~/.ssh/cm/... which is unwritable on such mounts, so any attempt to multiplex fails with: unix_listener: cannot bind to path .../cm/...: Read-only file system kex_exchange_identification: Connection closed by remote host The second line is downstream — when ControlMaster fails, ssh falls back to fresh TCP connections, and on residential CGNAT (most European ISPs) the per-(src,dst) concurrent-flow cap (~4) silently drops further SYNs once exceeded, manifesting as banner-exchange timeouts that look like a remote problem. Fix: bake /etc/ssh/ssh_config.d/00-devbox-controlmaster.conf in the base image with Host * defaults — ControlPath rooted at /tmp/sshcm/ (per-container, always writable), ControlMaster auto, ControlPersist 10m, ServerAlive{Interval=30,CountMax=6}. Companion entrypoint-user.sh creates /tmp/sshcm mode 700 on each container start (/tmp is per-container so the dir can't be baked into a layer; mode 700 is required by OpenSSH for ControlPath dirs). Debian's stock ssh_config sources ssh_config.d/*.conf before its own Host * block, so user ~/.ssh/config overrides still win. Two smoke assertions catch regressions: (a) the conf file exists, (b) ssh -G reports a controlpath rooted at /tmp/sshcm/ — second one catches the silent case where something later in the config chain shadows the bake-in. Discovered while running a recon shell from inside pi-devbox to a Proxmox node — fresh ssh hit banner-exchange timeout, debug output pointed at the read-only socket dir as the actual root cause. Cascades to all variants and to pi-devbox automatically on next build against base-latest. No size/threshold impact (~250-byte conf file).	2026-05-24 19:51:38 +00:00
joakimp	73a7f96056	Base: add gitleaks; surface git-crypt in smoke + docs ... Both tools are used as part of the secret-management setup in several of the repos this devbox operates on (gitleaks pre-commit hook + git-crypt for selectively-encrypted canonical config). Having them in the container means hooks fire correctly inside instead of warning 'gitleaks not installed' on every commit. git-crypt was already installed via apt in Dockerfile.base (line 58), just unasserted by smoke and unmentioned in user-facing docs. gitleaks is new: Go-compiled binary fetched from GitHub releases via the same /releases/latest redirect-resolution pattern as gosu, fzf, git-lfs, etc. Arch suffix is 'x64' (not 'x86_64' / 'amd64') on this project — flagged in the Dockerfile comment and in AGENTS.md's floated-binaries gotcha list. Adds ~21 MB to the base layer (gitleaks 8.30.1 binary). No variant threshold bumps needed (2500–3700 MB envelope, 21 MB is noise). CHANGES Dockerfile.base — new GITLEAKS_VERSION=latest ARG + install RUN right after the git-lfs block. Multi-arch (linux/amd64=x64, linux/arm64=arm64). Echoes resolved version + runs 'gitleaks version' to fail the build on any install error. scripts/smoke-test.sh — git-crypt and gitleaks added to the 'Resolved component versions' table (printed first thing in CI logs) and to the 'Core binaries' assertion list (run helper). Smoke now fails fast if either binary regresses. README.md — 'What's in the image' tree line names gitleaks alongside the existing git-crypt. AGENTS.md — gitleaks added to the 'GitHub-sourced binaries float by default' list with a new clause flagging project-specific arch-name deviations (gitleaks=x64, bat/eza/zoxide=x86_64/aarch64, gosu= amd64/arm64). Saves the next person from the 'why does this not download' debugging session. CHANGELOG.md — sub-entry under existing Unreleased, before the PI_VERSION/OMOS_VERSION cache-hit fix entry. DOWNSTREAM IMPACT This is a base-layer change — base-decide will compute a fresh base-<hash>, build-base will run (no cache hit), all four variants will rebuild. First real base rebuild since v1.14.50b. Pi-devbox's next FROM base-latest pull picks up gitleaks automatically with no Dockerfile change there. Verified end-to-end on host: gitleaks 8.30.1 21 MB binary extracts cleanly from the URL the Dockerfile constructs and 'gitleaks version' prints '8.30.1'. Holding off on tagging — opencode + pi upstreams unchanged at 1.15.10 and 0.75.5 respectively. Will ride along with the next upstream-bump release rather than burning a base rebuild on a no-upstream-change container-only roll.	2026-05-24 15:49:38 +00:00
joakimp	f7c34091b1	CI: preventative fix for PI_VERSION/OMOS_VERSION cache-hit silent regression ... Mirrors the pi-devbox v0.75.5b fix (2026-05-23) onto the four-variant pipeline here. The with-pi, omos, and omos-with-pi variants install upstream npm packages whose *_VERSION build-args defaulted to 'latest'. When the build-arg string is byte-identical across builds, the layer hash is identical and the registry buildcache silently reuses the layer from whatever upstream version was current when the cache was first populated — same mechanism that shipped pi-devbox v0.74.0..v0.75.5 with identical image bytes. Currently masked here because OPENCODE_VERSION is a hard-coded ARG that bumps every release; parent-chain cache invalidation flushes the downstream pi/omos layers. Masking would fail on any vN.N.Nb opencode- version-unchanged release that only bumps pi or omos. Filed last night as parked followup; fixing preventatively now that #5 (AWS SSO inside tor-ms22 container) cleared. CHANGES .gitea/workflows/docker-publish-split.yml — new resolve-versions job running 'npm view @earendil-works/pi-coding-agent version' and 'npm view oh-my-opencode-slim version', exposing concrete strings as job outputs. All six affected jobs (smoke-omos, smoke-with-pi, smoke-omos-with-pi, build-variant-omos, build-variant-with-pi, build-variant-omos-with-pi) now consume them as PI_VERSION / OMOS_VERSION build-args. smoke-base / build-variant-base unaffected. scripts/smoke-test.sh — new run_expect helper asserting an expected substring in command output. The pi check uses EXPECTED_PI_VERSION; the omos check uses EXPECTED_OMOS_VERSION against npm ls -g. Both env vars are wired from resolve-versions outputs in the smoke jobs. Catches this regression class on the next release, not four releases later. Dockerfile.variant — comment blocks above OPENCODE_VERSION (source- pinned, not subject to the bug), PI_VERSION (CI-resolved), and OMOS_VERSION (CI-resolved) explaining the cache-hit footgun. AGENTS.md — new convention bullet under 'Critical conventions' naming the resolve-versions job + EXPECTED_*_VERSION wiring as the contract to keep in lockstep when modifying variant build-args. .gitea/README.md — Step 1 expanded to cover the parallel resolve- versions job alongside base-decide; pipeline diagram updated. CHANGELOG.md — Unreleased entry describing the fix, masking mechanism, and audit footprint. No image-content change expected on the next release vs what 'latest' would have resolved to anyway. Purely makes the cache invalidate correctly going forward.	2026-05-24 15:38:36 +00:00
joakimp	8f2c9f5112	v1.15.4b: omos-with-pi threshold bump + update-description partial-publish fix ... Recovery for v1.15.4's partial publish (omos-with-pi exceeded 3500 MB smoke threshold; other 3 variants published cleanly). Two changes: 1. omos-with-pi threshold 3500 -> 3700 MB. Compounded growth from opencode 1.15.0 -> 1.15.4 (4 patch versions) plus pi 0.74.0 -> 0.75.3 (minor + 3 patches) summed in the omos-with-pi variant, just over the existing limit. Same pattern as prior threshold bumps (v1.14.31c, v1.15.0b). Restores ~150 MB headroom for routine apt-upgrade drift. 2. update-description workflow bug fix. Pre-existing latent bug exposed by v1.15.4's partial publish: update-description.needs includes all 4 build-variant-* jobs, and gitea Actions' default behavior is 'skipped need => skip dependent' \u2014 even when the job's own if: condition is satisfied. So when build-variant-omos-with-pi was skipped (because its smoke failed), update-description cascaded into a skip too, and Hub description didn't refresh on v1.15.4 despite 3 variants publishing. Fix: wrap if: in always() + explicit success check on the base variant. Same fix applied to promote-base-latest preemptively (it has the same latent bug, currently masked by the cache-hit gate). No image-side changes \u2014 cache hit on base-35ee5fe7861a.	2026-05-18 22:30:59 +02:00
joakimp	fde5a89e8b	README + DOCKER_HUB: lead with no-git-clone curl-template path ... The previous Quick Start in both surfaces led with 'git clone', which is overkill for users who just want to run the published image. Match pi-devbox's pattern: lead with 'mkdir; curl docker-compose.yml; curl .env.example; edit .env; docker compose run --rm devbox'. Keep the git-clone path as 'for hackers/forkers'. Required pre-step: make the gitea repo public so unauthenticated curl to the raw URL works (done out of band — repo was private until this commit landed).	2026-05-15 18:02:37 +02:00
joakimp	d293ddc202	v1.15.0b: bump omos smoke threshold 3200->3300, omos-with-pi 3400->3500 ... opencode 1.15.0 grew the omos image to 3206 MB, 6 MB over the existing 3200 MB threshold, causing smoke-omos to fail and build-variant-omos to be skipped in v1.15.0. Bump thresholds with ~100 MB headroom for routine apt-get upgrade drift. No image-side changes — pure smoke threshold update. v1.15.0b will hit the base hash cache and run only the variant deltas.	2026-05-15 10:35:08 +02:00
joakimp	910378fe06	v1.15.0: opencode bump + git clone retry + pi-devbox sibling mention ... - Bump OPENCODE_VERSION 1.14.50 -> 1.15.0 in Dockerfile.variant. - Wrap pi-toolkit/pi-extensions git clone in Dockerfile.variant in a 5-attempt retry loop with linear backoff (matches pi-devbox pattern). gitea.jordbo.se occasionally returns transient HTTP 500s that previously broke with-pi/omos-with-pi variant builds. - Add 'Sibling images' section to DOCKER_HUB.md mentioning joakimp/pi-devbox as the pi-only counterpart. - CHANGELOG entry for v1.15.0 with full notes.	2026-05-15 09:56:01 +02:00
joakimp	896380bb9c	Rename @mariozechner/pi-coding-agent to @earendil-works/pi-coding-agent ... Pi moved to its new home at earendil-works on 2026-05-07 (https://pi.dev/news/2026/5/7/pi-has-a-new-home). The old @mariozechner/pi-coding-agent npm package is deprecated with the explicit message 'please use @earendil-works/pi-coding-agent instead going forward', and the version stream has moved on (old top-out 0.73.1; new currently 0.74.0). Anyone npm-installing the old name today gets a deprecation warning + a stale binary, so this is a non-optional migration before the next tagged release. Sweep: - Dockerfile (production single-Dockerfile path) and Dockerfile.variant (split-base path on main): npm install -g target updated. - README, AGENTS, HUB_TEMPLATE: github.com/mariozechner/pi-coding-agent URL refs (which now 404) -> github.com/earendil-works/pi. - DOCKER_HUB.md regenerated (5529 bytes, ~78% headroom). - CHANGELOG Unreleased: rename entry added with migration context. Brew install references (`brew install pi-coding-agent`) left as-is: formula still works at 0.73.1 and a homebrew tap update is tracked upstream at earendil-works/pi#2755. Historical CHANGELOG entries: only github URL refs updated (the package name was never spelled out in those entries; we're correcting dead hyperlinks, not rewriting feature descriptions).	2026-05-09 17:58:07 +02:00
joakimp	911d6dd26b	smoke-test: query /usr prefix for npm ls -g ... The npm-prefix-on-volume fix (commit 9df126c) sets NPM_CONFIG_PREFIX=/home/developer/.pi/npm-global in the image ENV so user-installed pi packages survive container recreation. Side effect: default 'npm ls -g' now queries the user prefix, missing the baked opencode/pi/omos binaries that live in /usr. The smoke test's oh-my-opencode-slim check ran 'npm ls -g | grep ...' and started failing on validate-omos / validate-omos-with-pi after the prefix fix landed on main, even though the package itself is correctly installed and runnable. Fix: explicitly invert the prefix per-call: NPM_CONFIG_PREFIX=/usr npm ls -g --depth=0 | grep ... Other smoke checks (opencode --version, pi --version, bun --version) go through PATH which already includes /usr/bin, so they were unaffected. Only oh-my-opencode-slim was checked via npm rather than a binary-on-PATH because it's a library, not a CLI.	2026-05-09 17:13:22 +02:00
joakimp	f86c4b18cf	Rewrite DOCKER_HUB.md as a hand-maintained slim template ... The previous derive-from-README mechanism (split_sections, SECTION_RULES, TRIM_SUBSECTIONS, REPLACEMENTS) generated a 24 997 byte Hub doc with 3 byte headroom against the 25 kB Hub limit. Every README addition forced a 'trim something else first' exercise, and the resulting copy was awkward (terse, repetitive linkbacks injected mid-section). Replace with a single hand-maintained HUB_TEMPLATE constant. The Hub doc is now intentionally slim (~5.5 kB, ~78 percent headroom) and focuses on what Hub readers actually need: elevator pitch, image variants, quick start, what's inside, auth, persistence, and link-outs to the gitea README for depth. Trade-off: when image-variants or quick-start change, update HUB_TEMPLATE here too. That coupling is now explicit and local rather than spread across SECTION_RULES + REPLACEMENTS + TRIM machinery, and most README edits no longer require regenerating DOCKER_HUB.md at all. Generator simplified from 323 lines to 199 lines (270-line net reduction across the script + DOCKER_HUB.md). README and Hub doc are now independent surfaces. CHANGELOG and AGENTS updated to reflect the new coupling. Release-day checklist tightened: README -> regenerate DOCKER_HUB ONLY if HUB_TEMPLATE changed -> promote CHANGELOG -> grep AGENTS -> commit -> tag.	2026-05-09 15:49:43 +02:00
joakimp	9df126c7a9	Fix: developer-writable npm prefix for pi install ... NPM_CONFIG_PREFIX is now /home/developer/.pi/npm-global, with that prefix's bin/ prepended to PATH. Without this, 'pi install npm:<pkg>' (and any 'npm install -g') by the developer user would EACCES against the system prefix (/usr). The new prefix lives on the devbox-pi-config named volume, so: - User-installed pi packages (themes, skills, extensions) survive container recreate AND image rebuild, complementing pi's auto- restore from settings.json with one less cold-start step. - A user-driven 'npm install -g @mariozechner/pi-coding-agent' lands on the volume and wins over the baked pi via PATH order. Build-time 'npm install -g' calls (opencode, pi, oh-my-opencode-slim) are unaffected: the new ENVs are declared after those steps in the Dockerfile, so the baked binaries still install to /usr at build time and are not shadowed by the volume mount at runtime. Verified end-to-end with a Bun-driven smoke test: as developer, 'npm install -g cowsay' inside the container succeeds, the binary lands on PATH, and survives a fresh container against the same volume. DOCKER_HUB.md regenerated (24997/25000 bytes, 3-byte headroom — was 138 before; future README additions to the persistence section need to trim something else first). Docs updated: Dockerfile inline comments, README persistence section, AGENTS install contract, DOCKER_HUB persistence table, .env.example notes, CHANGELOG Unreleased entry.	2026-05-09 15:41:33 +02:00
joakimp	d01cff38d5	DOCKER_HUB: add tailored pi section (run, mempalace, persistence) ... Hub readers had no signal at all about pi beyond the variant tag names in the Image Variants table. The full README pi section is too large to include verbatim (would push past 25 kB), so this adds a custom `replace` rule in generate-dockerhub-md.py with a slimmed Hub-tailored version covering the three things a Hub user actually needs: - Run: how to start pi via compose run / compose exec - MemPalace integration: shared palace with opencode, mempalace.ts bridge symlinked at first start - Persistence: which paths are on volumes, what survives --rm, upgrade path for the pi binary itself Build args, extension list, and toolkit detail link out to the gitea README anchor for users who want full reference. DOCKER_HUB.md now 24862 bytes (138 byte headroom under the 25k limit).	2026-05-08 21:27:59 +02:00
joakimp	8083cd1a6f	docs: surface with-pi and omos-with-pi variants on Docker Hub ... The v1.14.41b release expanded the CI matrix to four image variants and pushed eight tags total, but the docs lagged behind: - DOCKER_HUB.md's Image Variants table still listed only base + omos. - README.md's pi section only described building from source; no mention that prebuilt latest-with-pi / latest-omos-with-pi tags exist (asymmetric vs the OMOS section which does mention latest-omos). Fix: - generate-dockerhub-md.py HEADER: extend Image Variants table to all four variants (base, omos, with-pi, omos-with-pi). - README.md pi section: add a Setup subsection mentioning the prebuilt pi-enabled tags, mirroring the OMOS section's pattern. - Regenerate DOCKER_HUB.md (22975 bytes, well under the 25k Hub limit). The pi section itself remains intentionally dropped from DOCKER_HUB.md to fit the 25k limit (SECTION_RULES); the Image Variants table at the top is sufficient signal for Hub readers.	2026-05-08 21:14:01 +02:00
joakimp	f46c4ed017	CI matrix: add with-pi and omos-with-pi build variants ... .gitea/workflows/validate.yml: Adds validate-with-pi (INSTALL_PI=true) and validate-omos-with-pi (INSTALL_OMOS=true + INSTALL_PI=true). amd64 single-arch with smoke test, no push. .gitea/workflows/docker-publish.yml: Adds smoke-with-pi → build-with-pi and smoke-omos-with-pi → build-omos-with-pi job pairs. Each push-by-digest multi-arch (amd64+arm64) to Docker Hub with two tags: ${VERSION}-with-pi + latest-with-pi ${VERSION}-omos-with-pi + latest-omos-with-pi update-description.needs[] extended to wait on both new build jobs. scripts/smoke-test.sh: bun-presence check now treats omos and omos-with-pi as the bun variants. Pi state assertions wait up to 30s for entrypoint-user.sh to finish deploying pi-toolkit + extensions (omos-with-pi has more setup work than the base+pi path; the previous sleep-1 was too short and caused empty-error assertion failures on cold starts). Local verification (arm64 via OrbStack): base → 1871 MB, all checks PASS omos → 2813 MB, all checks PASS with-pi → 2277 MB, all checks PASS omos-with-pi → 3030 MB, all checks PASS CI now produces 8 Docker Hub tags per release: vX.Y.Z[n], latest vX.Y.Z[n]-omos, latest-omos vX.Y.Z[n]-with-pi, latest-with-pi vX.Y.Z[n]-omos-with-pi, latest-omos-with-pi	2026-05-08 13:53:08 +02:00
joakimp	f51e9f52a1	Add INSTALL_PI build arg for pi as second harness ... Optional integration of pi-coding-agent alongside opencode in the same container. Both harnesses share the mempalace install and palace path — wing/diary entries are mutually visible. Build: --build-arg INSTALL_PI=true # opt-in --build-arg PI_VERSION=0.73.1 # pin a version (default: latest) --build-arg INSTALL_OPENCODE=false # build pi-only image Dockerfile: • New INSTALL_PI block: npm install -g @mariozechner/pi-coding-agent + git-clones pi-toolkit and pi-extensions to /opt/. • Existing opencode install gated behind new INSTALL_OPENCODE arg (default true; existing builds unaffected). • mkdir adds ~/.pi/agent/extensions for the named volume mount root. • CMD changed from ['opencode'] to ['bash', '-l']. compose run --rm devbox now drops to a login shell so users pick the harness; pass 'opencode' or 'pi' explicitly to launch directly. compose exec workflows are unaffected (bypass entrypoint+CMD). entrypoint.sh: • Adds ~/.pi to volume ownership loop. entrypoint-user.sh: • New 'pi: deploy toolkit + extensions + mempalace bridge' block runs pi-toolkit/install.sh, pi-extensions/install.sh, settings.json template bootstrap, then symlinks the mempalace.ts bridge directly. Order: toolkit before extensions before bridge. mempalace-toolkit's full install.sh is intentionally NOT called (its install_skill would race with skillset auto-deploy --prune-stale). docker-compose.yml: • New devbox-pi-config named volume mounted at /home/developer/.pi. Persists user toggles (/ext-disabled extensions) and settings.json edits across container recreate. Mirrors devbox-opencode-config pattern from v1.14.33. scripts/smoke-test.sh: • New --variant with-pi (threshold 2700 MB) and --variant omos-with-pi (3400 MB). • Pi assertions gated on `command -v pi`: version, /opt/pi-toolkit clone HEAD, /opt/pi-extensions clone HEAD, deployed keybindings symlink, ≥4 extension symlinks, mempalace.ts bridge symlink, settings.json bootstrap. • Pi state assertions use docker exec from the host (not 'run'), since the container has no docker CLI. • opencode core test now gated on INSTALL_OPENCODE presence. scripts/generate-dockerhub-md.py: • SECTION_RULES adds 'pi (alternative/complementary harness)': drop. Section stays in README; dropped from DOCKER_HUB.md to keep under the 25 kB Docker Hub limit. Docs: • README adds full 'pi (alternative/complementary harness)' section. • AGENTS.md codifies pi install contract, deploy ordering, named volume rationale, and CMD change. • CHANGELOG.md gets an Unreleased entry. • .env.example documents new build args. • docker-compose.yml example args block updated. Verification (local builds on arm64): • Default (INSTALL_PI=false): 1871 MB, all assertions pass — no regression. • INSTALL_PI=true: 2110 MB (within 2700 threshold), 37 assertions pass including pi version, all 7 extensions deployed (6 from pi-extensions + mempalace.ts bridge), settings.json bootstrap. Not yet: • CI workflow updates to add -with-pi tag variants. Deferred until local path stabilizes through user testing. • pi-devbox separate repo for fully stripped pi-only image. Phase 2.	2026-05-07 23:58:37 +02:00
joakimp	a803fe4653	Fix smoke-test JSONC parsing to respect URLs ... The previous 'sed "s|//.*$||"' approach greedily stripped '//' from URLs like https://mcp.context7.com/mcp, corrupting the JSON and causing smoke-test failures with json.decoder.JSONDecodeError. Replaced the sed step with a Python regex that respects string literals so URLs pass through while only line comments are removed.	2026-05-03 10:34:16 +02:00
Joakim Persson	3e3abc8672	Update docs for named volume config, skillset auto-deploy, opencode.jsonc ... - README: rewrite config/skills sections for named volume and auto-deploy, add Context7 MCP docs, update all opencode.json→opencode.jsonc refs, add SKILLSET_CONTAINER_PATH to env var table - CHANGELOG: add v1.14.32b entry documenting breaking changes and features - AGENTS.md: update file roles, add skillset and config volume conventions - DOCKER_HUB.md: regenerated (drop Context7 and Shell defaults sections to stay within 25KB Docker Hub limit) - generate-dockerhub-md.py: add Context7 (drop) and Shell defaults (drop) to SECTION_RULES	2026-05-02 23:00:41 +00:00
Joakim Persson	3d4e739529	Add Context7 remote MCP server to auto-generated config ... Context7 provides up-to-date library documentation for LLMs via a remote endpoint — no local binary needed. Always registered since it has no PATH dependency. Also switches generated config from .json to .jsonc so we can include a comment about the optional API key for higher rate limits. The existing-config check now detects both file extensions.	2026-05-02 21:24:04 +00:00
Joakim Persson	5a2d06340e	Fix dash-incompatible slash substitution and bump omos size threshold ... v1.14.31b made it through smoke-base and validate-base (reclaim worked), but two narrow bugs blocked the rest: 1. 'Derive platform slug' in the per-arch matrix jobs used bash ${PLATFORM_PAIR//\//-} which dash (/bin/sh in the runner) can't parse — 'Bad substitution'. Rewrote with 'tr / -'. 2. smoke-omos image size 3107 MB tripped the 3000 MB guardrail. All functional checks pass; the mempalace-toolkit bake-in from v1.14.30b added ~100 MB and the threshold was stale. Bumped to 3200 MB. No image-level changes.	2026-05-01 10:43:04 +00:00
Joakim Persson	1683650240	Bake mempalace-toolkit wrappers into the image ... The scheduler templates in mempalace-toolkit's contrib/ assume mempalace-session is available inside the container, but the image never actually installed it. Users following the *-devbox scheduler docs would silently lose the wrappers on every container recreate, because the only way to get them was a post-hoc install.sh inside the container — which lives in the ephemeral layer. The host-side systemd timer would then fire, docker exec in, and hit "mempalace-session: command not found". Caught during runtime validation on 2026-04-30: host-side systemd unit ran cleanly at 16:15 today, then the container was rebuilt and recreated, and the wrappers were gone. The rebuild produced an image that the scheduler template's own documented precondition did not hold for. Fix: new Dockerfile block clones mempalace-toolkit at build time (depth-1) to /opt/mempalace-toolkit/, symlinks bin/mempalace-session and bin/mempalace-docs into /usr/local/bin/, asserts both respond to --help before the layer succeeds. Gated by INSTALL_MEMPALACE_TOOLKIT=true (defaults on, depends on INSTALL_MEMPALACE=true). Floated ref via MEMPALACE_TOOLKIT_REF=main for auto-picking-up toolkit updates; override for reproducible builds once the toolkit starts tagging releases. Smoke test gains three assertions (mempalace-session --help, mempalace-docs --help, symlink target check). Resolved-versions preamble logs the toolkit git short-SHA alongside the other floated components, so CI logs always record what got baked in. README gains a Scheduled mining (mempalace-toolkit) subsection and a build-args row. DOCKER_HUB.md regenerated; sync-check passes.	2026-04-30 20:56:58 +00:00
joakimp	23bae2ab7d	Use mempalace-mcp entry point directly, drop redundant wrapper ... The mempalace Python package ships a 'mempalace-mcp' console entry point; 'uv tool install' places it on PATH as a shim whose shebang points at the isolated venv's Python. Our hand-rolled wrapper at /usr/local/bin/mempalace-mcp-server was duplicating what uv installs for free — one less file to maintain. Fixes the MCP error users saw after the v1.14.28b → v1.14.29 upgrade path: custom opencode.json files typically had the pre-v1.14.29 command ['python3', '-m', 'mempalace.mcp_server'] which worked with the old pip install but fails silently after the uv-tool migration because system python3 cannot import from the venv. Opencode surfaced this as 'MCP error -32000: connection closed'. - generate-config.py now emits ['mempalace-mcp'] and keys its detect on shutil.which('mempalace-mcp'). - Dockerfile drops 'COPY rootfs/usr/local/bin/' and the chmod of the wrapper. Build shrinks from 30 to 29 stages. - rootfs/usr/local/bin/ removed entirely. - Smoke test asserts /usr/local/bin/mempalace-mcp is executable and prints its symlink target. - README's MemPalace section shows ['mempalace-mcp'] and explicitly warns against the old pattern with the observed failure mode. - CHANGELOG adds a v1.14.29c entry.	2026-04-29 15:27:30 +02:00
joakimp	349bb633ff	Fix OMOS bunx detection ... entrypoint-user.sh gated OMOS auto-install on 'command -v bunx', but neither upstream bun installer nor our Dockerfile creates a bunx symlink — only the bun binary exists on PATH. The check always failed on a fresh OMOS image, printing 'ENABLE_OMOS=true but bun is not installed.' even though bun was right there. Latent until now because the only exercised path had a persisted oh-my-opencode-slim.json from a prior install. Fixes: - Gate on 'command -v bun' instead of bunx. - Call 'bun x oh-my-opencode-slim@latest install ...' (bun x is the real subcommand that actually works with only the bun binary). - Add 'ln -sf bun /usr/local/bin/bunx' in the Dockerfile OMOS block so interactive users can still type bunx by habit. - Smoke test asserts the bunx symlink exists on the OMOS variant. Also verify 'test -L /usr/local/bin/bunx' as a build-time sanity check. Can't use 'bunx --help' for that — bun exits 1 on help output even though it prints the usage correctly.	2026-04-29 09:01:23 +02:00
joakimp	113c9f0bb0	Infrastructure pass: CI smoke tests, floating versions, chown sentinel, generate-config script ... Main changes: - Extract opencode.json generation from entrypoint-user.sh into a standalone Python script (rootfs/usr/local/lib/opencode-devbox/ generate-config.py). Preserves the never-overwrite-existing-config guarantee. Cuts entrypoint-user.sh from 176 to 97 lines. - Install MemPalace via 'uv tool install' into an isolated venv at /opt/uv-tools/mempalace/ with a /usr/local/bin/mempalace-mcp-server wrapper, replacing the 'pip install --break-system-packages' escape hatch. The wrapper is what generate-config.py references in the auto-generated opencode.json. Also fix 'mempalace init' in entrypoint-user.sh to use --yes so first-start initialization isn't interactive (this used to hang or print prompts into the user's terminal). Gated by INSTALL_MEMPALACE build arg (default true) so users who don't need AI memory can shave ~300 MB. - Sentinel-file pattern in entrypoint.sh volume-ownership loop: write .devbox-owner after a successful chown -R, skip the recursive walk on subsequent starts when the sentinel matches FINAL_UID:FINAL_GID. Cuts multi-second startup costs to milliseconds on large volumes (nvim plugins, palace data). UID changes still trigger a full chown. - Float all GitHub/Gitea-hosted binary versions: gosu, fzf, git-lfs, neovim, bat, eza, zoxide, uv, gitea-mcp now default to 'latest' and resolve the newest upstream release at build time via the /releases/ latest redirect. Go (go.dev JSON feed) and oh-my-opencode-slim (npm @latest) likewise. Intentional pins still in place: OPENCODE_VERSION, NODE_VERSION=22, DEBIAN_VERSION=trixie-slim. Each *_VERSION ARG accepts an explicit value to lock a specific version when needed. - New scripts/smoke-test.sh verifies binary presence, opencode startup, entrypoint user drop, generate-config idempotency, bun's presence- per-variant, and image size against thresholds (2500 MB base, 3000 MB OMOS). Prints resolved component versions as its first step so CI logs always record what got baked into a given image. - New .gitea/workflows/validate.yml runs on push to main and PRs: single-arch amd64 build, smoke test, DOCKER_HUB.md sync check. Tag- triggered docker-publish.yml now smoke-tests each variant on amd64 before the full multi-arch push. - scripts/generate-dockerhub-md.py auto-generates DOCKER_HUB.md from README.md using explicit SECTION_RULES. --check mode fails CI when the committed file is out of sync. Enforces the 25 kB Docker Hub limit. Adding a new README section forces an explicit keep/drop/ replace decision. - Remove dead INSTALL_PYTHON build arg (was a no-op since mempalace added python3 unconditionally).	2026-04-28 23:28:43 +02:00