191 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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. v1.15.4b	2026-05-18 22:30:59 +02:00
joakimp	60eb49469e	v1.15.4: bump opencode 1.15.3 -> 1.15.4 ... Bundles with the CI hardening landed on main since v1.15.3 (T14/T15 in the operator backlog): - Pinned crane install in promote-base-latest (replaces flaky imjasonh/setup-crane@v0.4 that depends on api.github.com/releases/latest at runtime and periodically rate-limits) - Skip promote-base-latest on cache-hit base builds (need_build='false') These will be exercised on this release run \u2014 if the base hash hasn't drifted since v1.15.3 (likely cache hit), promote-base-latest should SKIP rather than RUN, and update-description picks up the new tag. v1.15.4	2026-05-18 21:51:15 +02:00
joakimp	18b9c9c549	CI: harden promote-base-latest (pinned crane + skip on cache-hit) ... Two workflow-only changes for promote-base-latest, no image-side impact: T14 \u2014 replace imjasonh/setup-crane@v0.4 with direct pinned crane install. The action's bootstrap script calls api.github.com/.../releases/latest at every run to discover the crane version. That call periodically rate-limits and returns JSON without .tag_name, jq emits 'null', the action then downloads .../releases/download/null/... \u2192 404 \u2192 'gzip: unexpected end of file' \u2192 exit 2. We hit this on the v1.15.3 release (2026-05-16) where it was cosmetic only \u2014 base-latest was already correct from cache hit \u2014 but the red-X is annoying. Replaced with curl + tar pinned to crane v0.21.6 (latest at time of change). Same pattern as other GitHub-sourced binaries in the Dockerfile layer (gosu, fzf, eza etc.); operator bumps CRANE_VERSION deliberately when wanting updates. T15 \u2014 gate promote-base-latest on need_build == 'true'. When the base layer's content hash hasn't changed (cache hit on existing base-<hash> from a prior run), base-latest already points at the correct digest. The retag is a tautology, and any transient failure of it produces a red-X for an operation that didn't need to happen. Skipping the job entirely on cache-hit is correct and removes a whole class of cosmetic failure. Manual workflow_dispatch with promote_latest=true still bypasses the gate as an escape hatch (e.g., if base-latest got hand-deleted and needs regeneration without rebuilding the base). This will not trigger a CI publish run (main-branch commit, no tag).	2026-05-18 21:45:10 +02:00
joakimp	ad4a12b3ab	v1.15.3: bump opencode 1.15.0 -> 1.15.3 v1.15.3	2026-05-16 19:54:15 +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	034830710c	workflow: use github.ref_type directly in promote/update-description if-conditions ... Gitea Actions evaluates 'env.PROMOTE_LATEST' as empty in YAML 'if:' contexts even though the same env var substitutes correctly in shell run: blocks. Result: on v1.15.0/v1.15.0b tag pushes, the build-variant-* jobs correctly pushed latest-* aliases (shell context), but promote-base-latest and update-description got skipped (YAML context), so the Hub README description wasn't refreshed. Switch to evaluating github.ref_type directly in the if-conditions — matches the production-trigger semantics and avoids the env-var indirection that gitea evaluates inconsistently.	2026-05-15 13:50:46 +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. v1.15.0b	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. v1.15.0	2026-05-15 09:56:01 +02:00
joakimp	f06a70a3bc	v1.14.50c: tag-only retag to recover v1.14.50b's missing variants ... CHANGELOG entry for v1.14.50c with full postmortem on the v1.14.50/50b runner-fleet incident (AVX shadowing + containerd race + Proxmox CPU default + base-latest auto-promote gap). No container-side code changes \u2014 the rebuild on the now-healthy fleet is sufficient. v1.14.50c	2026-05-14 23:32:46 +02:00
joakimp	dba05da7d1	validate.yml: use Hub base-latest as variant parent + warn on base-input changes ... The previous two-step approach (build Dockerfile.base \ then Dockerfile.variant FROM the local image) doesn't work: each docker/build-push-action@v7 invocation runs in its own buildx container context, and an image loaded into the host docker daemon by step N is not visible to step N+1's buildx invocation. Variant builds in validate.yml now FROM joakimp/opencode-devbox:base-latest on Docker Hub, matching the production smokes' parent. Trade-off: PRs/pushes that change Dockerfile.base, rootfs/, or entrypoint*.sh are not exercised here \u2014 only release tags rebuild the base via docker-publish-split.yml. The new base-change-warning job surfaces a runtime warning when a commit modifies any base-image input, telling the author to run a workflow_dispatch test if they want full validation before merging.	2026-05-14 20:53:19 +02:00
joakimp	8359fef949	Force fresh base rebuild for v1.14.50b ... Add BASE_REBUILD_DATE comment to Dockerfile.base to invalidate the content hash and trigger a full base rebuild. Picks up ~5 days of Debian trixie security updates since the previous base-bf9df274db7a was built on 2026-05-09. The comment also documents the pattern for future intentional base-rebuilds without other code changes — recommended cadence is once per release for security currency. Required because v1.14.50 hash inputs were unchanged from v1.14.44, hitting the existing base-bf9df274db7a cache and shipping stale apt packages. v1.14.50 also failed mid-flight before promote-base-latest could publish base-latest to Hub — pi-devbox and other downstream images that FROM base-latest were blocked. v1.14.50b	2026-05-14 20:17:37 +02:00
joakimp	a438c67f06	fix: update validate.yml for split-base Dockerfiles ... Replace single-Dockerfile build with two-step: build Dockerfile.base first (loads as opencode-devbox:validate-base), then build Dockerfile.variant with BASE_IMAGE pointing at the local base image. All four validate jobs updated.	2026-05-14 19:48:46 +02:00
joakimp	07e07ec611	Bump opencode 1.14.44 -> 1.14.50; cut over to split-base pipeline ... - Bump OPENCODE_VERSION 1.14.44 -> 1.14.50 in Dockerfile.variant - Cut over: docker-publish-split.yml now triggers on push: tags: v* (was workflow_dispatch only). RELEASE_TAG and PROMOTE_LATEST derived from github.ref_type/ref_name for tag-push; inputs still available for manual workflow_dispatch runs. - Delete docker-publish.yml (retired, replaced by split-base pipeline) - Delete Dockerfile (retired, replaced by Dockerfile.base + Dockerfile.variant) - Update CHANGELOG: promote Unreleased -> v1.14.50 - Update AGENTS.md, .gitea/README.md, validate.yml: remove all references to the old single-Dockerfile pipeline and WIP migration plan v1.14.50	2026-05-14 19:39:45 +02:00
joakimp	7dc836ab66	fix: replace echo -e heredoc with brace-block in build-variant tags steps ... echo -e doesn't interpret \n in /bin/sh (dash), which is the default shell in catthehacker/ubuntu:act-latest. This caused steps.tags.outputs.tags to be empty, resulting in 'tag is needed when pushing to registry' from buildx. Also fixes a secondary bug: TAGS='${TAGS}\n...' stored a literal backslash-n rather than a real newline, which would have broken multi-tag output when promote_latest=true. Fix: replace with a brace block using plain echo, which produces actual newlines and works in both sh and bash.	2026-05-10 11:59:04 +02:00
joakimp	a3ff601bf0	Bump opencode 1.14.42 -> 1.14.44; close v1.14.42 omos-with-pi gap ... opencode-ai 1.14.44 published 20:26 UTC (1.14.43 skipped upstream). Bumping to 1.14.44 instead of re-running the failed v1.14.42 build gives us the same 3h CI cost and picks up upstream bug fixes. Closes the v1.14.42 omos-with-pi gap. The v1.14.42 tag's build-omos-with-pi job failed during publish: oh-my-opencode-slim@1.0.7 had been published with a dependency on @opencode-ai/sdk@1.14.44, and our build hit the npm registry within ~2 minutes of that SDK version landing -- before the tarball had propagated across npm's CDN. The manifest's dist-tags.latest pointed at 1.14.44 but a tarball fetch on /-/sdk-1.14.44.tgz returned 404. Tarball is now fully fetchable. Result on Docker Hub once v1.14.44 publishes: v1.14.42 / latest -> stable (3 of 4 variants) v1.14.42-omos / latest-omos -> stable v1.14.42-with-pi / latest-with-pi -> stable v1.14.42-omos-with-pi -> NEVER PUBLISHED (404 if pulled) latest-omos-with-pi -> still v1.14.41b until v1.14.44 v1.14.44 / latest -> NEW (replaces latest) v1.14.44-omos / latest-omos -> NEW v1.14.44-with-pi / latest-with-pi -> NEW v1.14.44-omos-with-pi / latest-omos-with-pi -> NEW (closes the gap) CHANGELOG: v1.14.44 entry added with the propagation-race rationale, v1.14.42 entry annotated with the known gap. Reverse-chrono preserved. v1.14.44	2026-05-09 22:33:16 +02:00
joakimp	6fde27c212	Document the build pipeline architecture in .gitea/README.md ... The split-base build architecture, the NPM_CONFIG_PREFIX gotcha, the hash-driven base cache reuse mechanism, and the cutover plan from docker-publish.yml to docker-publish-split.yml were previously scattered across: - inline Dockerfile.base / Dockerfile.variant comments - CHANGELOG Unreleased entries - AGENTS.md mentions - docker-publish-split.yml header comment - my own session notes Consolidate into .gitea/README.md as the canonical architectural doc. Gitea (like GitHub) auto-renders this when navigating to .gitea/ in the web UI, so anyone investigating 'why is CI shaped this way?' finds it on the first click. Cross-referenced from AGENTS.md as the first thing to read when touching CI. Covers: - The two release pipelines and why both exist - Why split-base: cross-variant cache misses on layer-hash-divergence - The 6 phases of the split-base pipeline with an ASCII diagram - base-decide hash inputs and Docker Hub probe logic - NPM_CONFIG_PREFIX variant-override pattern (the volume-shadow trap) - Registry cache strategy (mode=max for cross-arch reuse) - Wall-clock estimates: version-bump vs base-touching releases - Validate workflow role - Runner expectations: catthehacker image, disk reclaim, concurrency, Gitea Actions @v4 artifact incompatibility - 4-step migration plan from docker-publish.yml to .split.yml - Cross-refs to related docs Does not duplicate AGENTS.md content; links to it for domain facts and release-day checklist.	2026-05-09 19:28:03 +02:00
joakimp	b30ffc83bd	Bump opencode 1.14.41 -> 1.14.42 ... opencode-ai 1.14.42 was released; bump OPENCODE_VERSION default in Dockerfile and Dockerfile.variant. Container changes accumulated since v1.14.41b ride along with this tagged release: pi package rename to @earendil-works/*, npm-prefix-on-volume fix, smoke-test query fix, Hub doc rewrite, README/AGENTS docs catchup. CHANGELOG promoted: Unreleased -> v1.14.42 (2026-05-09). The split-base build pipeline note stays under a fresh Unreleased \u2014 it's merged to main but not yet validated end-to-end via dispatch test, so it does not ship with v1.14.42 (the production docker-publish.yml on tag push is still authoritative). Release contents: - Bump: opencode 1.14.41 -> 1.14.42 - Rename: @mariozechner/pi-coding-agent -> @earendil-works/pi-coding-agent - Fix: NPM_CONFIG_PREFIX on volume so 'pi install npm:<pkg>' as developer survives container recreate AND image rebuild - Fix: smoke-test queries /usr prefix for npm ls -g check - Docs: Hub doc rewrite (24997 -> 5529 bytes), README pi section catchup (6 -> 7 extensions, mcp-loader documented), AGENTS release-day checklist updates v1.14.42	2026-05-09 19:17:10 +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	4c27e6fd8a	feat: split-base build pipeline (parallel, manual-trigger only) ... Two-Dockerfile split-base build alongside the existing single-Dockerfile pipeline. Goal: cut CI wall clock from ~165-180min to ~30-40min on typical version-bump-only releases by reusing a base image across the four variants. Files added: - Dockerfile.base variant-independent layers (apt, locales, AWS CLI, Node.js, mempalace, gitea-mcp, user setup, chromadb prewarm, ENVs, entrypoints). - Dockerfile.variant FROMs ${BASE_IMAGE} and adds opencode / pi / omos / Go installs gated by INSTALL_* args. Each npm install -g uses NPM_CONFIG_PREFIX=/usr per-RUN to keep baked binaries off the volume- shadowed ~/.pi/npm-global path inherited from base. - .gitea/workflows/docker-publish-split.yml workflow_dispatch-only pipeline: base-decide -> build-base (conditional) -> smoke-* (4 parallel) -> build-variant-* (4 parallel) -> promote-base-latest -> update-description. Hash-driven base reuse: if base-<sha> already exists on Docker Hub, the build is skipped entirely. Inputs: release_tag (test tag suffix, default v0.0.0-split-test) and promote_latest (default false; gates latest-* aliases and Hub description update). Files unchanged: - Dockerfile, docker-publish.yml, validate.yml all left in place so the production tag-push pipeline keeps working untouched. Migration plan (in CHANGELOG Unreleased): 1. workflow_dispatch test run with promote_latest=false; verify the four variant images smoke-pass and have plausible sizes. 2. Compare manifest digests against the same-version output from the production pipeline (independent test run on the same commit). 3. Once verified across 1-2 release cycles, swap docker-publish-split.yml to on: push: tags: v* and retire docker-publish.yml. AGENTS.md and CHANGELOG.md updated with file roles and the migration plan. Production pipeline behavior is bit-for-bit unchanged on this branch.	2026-05-09 16:16:25 +02:00
joakimp	b5da6a5cf8	README: pi 'What gets installed' section catchup ... Was stale: - Claimed 6 pi-extensions (actually 7 — mcp-loader was added in pi-extensions 141bf64 / 7eec49b / 37cc49e but the count was never propagated here). - No mention of mcp-loader's dual-transport (local stdio + remote streamable-HTTP per MCP spec 2025-03-26) or the /mcp slash command. - Mempalace bridge bullet didn't note that it coexists with mcp-loader rather than being replaced by it (don't list mempalace in mcp block). - No explicit 'no MCP servers baked in' line, leaving readers to guess whether searxng/context7 ship by default. Each extension now gets a one-line description; mcp-loader gets a paragraph covering its capabilities and a link to the pi-extensions AGENTS for transport detail. Added an opt-in note for MCP servers.	2026-05-09 15:54:48 +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	148f4bce8c	AGENTS.md: expand doc-coupling rule with release-day checklist ... The previous 'Two docs to keep in sync' bullet only mentioned README + DOCKER_HUB.md + .env.example. Today's session surfaced two additional drift points the rule didn't cover: - CHANGELOG.md still claimed 'Unreleased — will become v1.14.41b on release' even though the tag had been pushed and shipped (caught a full session later when user asked about doc drift). - AGENTS.md itself carried stale 'four Docker Hub tags' / 'four load:true jobs' from before the v1.14.41b CI matrix expansion to eight. Replaced the bullet with a full 'Documentation coupling on release' rule listing all four coupled docs (README, DOCKER_HUB.md, CHANGELOG.md, AGENTS.md, plus .env.example) and an explicit release-day checklist. Calls out the 25 kB Hub limit on DOCKER_HUB.md as a hard constraint to keep in mind when adding sections to README.	2026-05-08 21:35:23 +02:00
joakimp	cc98722d84	docs: catch up CHANGELOG and AGENTS.md with v1.14.41b reality ... CHANGELOG drift: - 'Unreleased' still claimed 'Will become v1.14.41b on release' even though the tag was cut and shipped today. Promoted to a proper '## v1.14.41b — 2026-05-08' release header (re-ordered above v1.14.41 to keep reverse-chronological invariant). - New 'Unreleased' entry records today's docs-only updates (commits 8083cd1, d01cff3, this commit) which were patched to Docker Hub via the API rather than re-tagging. AGENTS.md drift introduced by the v1.14.41b CI matrix expansion: - 'CI produces four Docker Hub tags per release' → eight (one tag pair per build variant: base, omos, with-pi, omos-with-pi). - 'all four `load: true` jobs (validate-base, validate-omos, smoke-base, smoke-omos)' → all eight (added validate-with-pi, validate-omos-with-pi, smoke-with-pi, smoke-omos-with-pi). DOCKER_HUB.md unchanged (already in sync, regenerator confirms).	2026-05-08 21:32:11 +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 v1.14.41b	2026-05-08 13:53:08 +02:00
joakimp	bf811f2170	Merge main (v1.14.41 bump) into feat/install-pi ... # Conflicts: # CHANGELOG.md	2026-05-08 13:46:03 +02:00
joakimp	c76b1e8aa3	Bump opencode to 1.14.41 ... Restored formatter output handling for stdout/stderr-writing formatters; warping a session to another workspace can now carry over uncommitted file changes; restored custom provider setup in /connect; macOS Settings menu entry; desktop local server split into a separate utility process; ACP clients restore last model/mode/effort when loading sessions and can close sessions cleanly. No container-level changes. v1.14.41	2026-05-08 13:08:50 +02:00
joakimp	23bf383a37	Fix mempalace init hang on stdin in docker run -it ... mempalace init has an interactive 'Mine this directory now? [Y/n]' prompt at the end that --yes does not auto-answer in all paths (notably empty or near-empty workspaces). The entrypoint redirected stdout/stderr to /dev/null but left stdin connected to the TTY. When invoked from 'docker run -it' the process blocked forever on stdin with 0% CPU, silently — the user's symptom of 'still hangs at Initializing MemPalace for workspace'. Fix: redirect stdin from /dev/null too. EOF on stdin makes the prompt fall through to its default (skip), and the process exits cleanly. Verified locally: fresh-container start now completes in 1.3 seconds (vs hanging indefinitely).	2026-05-08 00:36:02 +02:00
joakimp	5006b01170	Pre-warm chromadb embedding model at build time ... Mempalace's embedding function is chromadb's ONNXMiniLM_L6_V2, which downloads ~80 MB of all-MiniLM-L6-v2 ONNX weights from chromadb's CDN on first use. Without pre-warming this happened silently in the entrypoint init step (output redirected to /dev/null) and stalled first container start by multiple minutes on slow networks — the symptom user reported as 'hangs at Initializing MemPalace for workspace'. Fix: invoke the embedding function once at build time as gosu developer so the cache lands at the runtime user's ~/.cache/chroma/onnx_models/all-MiniLM-L6-v2/ with correct ownership and survives container recreate (cache path is not on a named volume, so it lives in the image layer). Build-time cost: ~3-5 s to download. Runtime saving: minutes per fresh container. Image size: 2110 → 2277 MB for the with-pi variant. Still within the 2700 MB smoke-test threshold.	2026-05-08 00:25:22 +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	a208b073b0	Bump opencode to 1.14.40 ... Rolls up upstream v1.14.34 through v1.14.40 (no v1.14.36 was published). Highlights: .well-known/opencode remote config support; HTTP_PROXY honored in desktop app; CORS/CSP fixes; warp-session-to-workspace feature; PTY auth tickets; v2 session failure events; debug info CLI command. No container-level changes. v1.14.40	2026-05-07 10:52:50 +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. v1.14.33	2026-05-03 10:34:16 +02:00
joakimp	79b697dea0	Bump opencode to 1.14.33	2026-05-03 10:31:17 +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	59e58a9d00	Use named volume for opencode config instead of host bind mount ... Switching from a host bind mount (~/.config/opencode) to a named volume (devbox-opencode-config) eliminates the symlink conflict between host and container environments. Each manages its own skill/instruction symlinks independently, allowing native opencode and containerized opencode to coexist on the same machine. Also removes the ~/.agents/skills bind mount recommendation — the container manages its own skills directory via the entrypoint deploy, and sharing it with the host causes relative-path conflicts.	2026-05-02 22:50:09 +00:00
Joakim Persson	26ce9aa490	Auto-deploy skillset on container start for portable skill resolution ... Add entrypoint logic to detect and run the skillset deploy script on container start. Detection order: SKILLSET_CONTAINER_PATH env var, then ~/skillset dedicated mount, then /workspace/skillset fallback. The deploy script (from the skillset repo) creates relative symlinks that resolve inside the container regardless of the host path layout. Also adds SKILLSET_PATH volume mount option to docker-compose files and documents SKILLSET_CONTAINER_PATH in .env.example for hosts where the skillset lives in a workspace subdirectory.	2026-05-02 22:21:57 +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
joakimp	a6b0b59946	Bump opencode to 1.14.32	2026-05-02 18:04:00 +02:00
Joakim Persson	fc74a8f906	Collapse per-arch matrix back into single multi-arch push jobs ... v1.14.31c's matrix jobs failed on Upload digest with GHESNotSupportedError — Gitea Actions doesn't support actions/upload-artifact@v4+. Separately, build-omos arm64 hung silently for 12 min in Set-up job, likely catthehacker pull contention between concurrent matrix children. Rather than downgrade artifacts to @v3, collapse the matrix entirely. docker/build-push-action@v7 with platforms: linux/amd64,linux/arm64 publishes a proper multi-arch manifest in one job, so the artifact-passing and imagetools create merge dance only existed to support a matrix split we no longer need. The matrix was designed around load: true disk exhaustion (v1.14.30b), but push-by-digest streams straight to the registry with fundamentally different disk profile. Reclaim step gives enough headroom for the combined amd64+arm64 push case. Workflow: 7 jobs → 5. docker-publish.yml: 263 → ~110 lines of YAML. Also: - timeout-minutes: 90 on build jobs so hung builds fail explicitly - BUILDKIT_PROGRESS=plain at workflow level for line-by-line arm64 logs - AGENTS.md §CI quirks documents the Gitea-specific traps (upload-artifact@v3-only, dash-not-bash, build-push-action@v7 multi-arch convention, reclaim requirement) v1.14.31d	2026-05-01 12:28:34 +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. v1.14.31c	2026-05-01 10:43:04 +00:00
Joakim Persson	23894bc19f	Reclaim runner disk before load: true smoke builds ... v1.14.31 publish and validate both hit 'No space left on device' on single-arch amd64 smoke/validate builds. The image has crossed ~3 GB and the runner's ~40 GB overlay starts ~70% full, so 'load: true' peak disk (tarball + unpacked image + buildx cache) no longer fits. Add a 'Reclaim runner disk' step to validate-base, validate-omos, smoke-base, smoke-omos. Strips catthehacker-resident toolchains we never use (hosted-tool-cache, dotnet, android, powershell, swift, ghc, jvm, microsoft, chromium, boost), then runs 'docker system prune -af --volumes' + 'docker builder prune -af' against the runner's dockerd before setup-buildx-action. Expected reclaim is 6-12 GB depending on what's resident. Deliberately NOT in the per-arch matrix build jobs — push-by-digest doesn't need it and pruning in parallel jobs risks one job nuking another's in-flight buildx cache. Also add workflow-level concurrency on docker-publish.yml so concurrent tag pushes serialize cleanly. v1.14.31b	2026-05-01 09:34:52 +00:00
Joakim Persson	f0918ba915	Bump opencode to 1.14.31 and split multi-arch publish across runners ... The v1.14.30b publish failed on both variants with 'No space left on device' — arm64 QEMU-emulated layers were stored alongside amd64 on the same ~40 GB runner, and the mempalace-toolkit bake-in from v1.14.30b tipped peak disk over the edge during the nodejs dpkg unpack and the git-lfs layer export. Refactor docker-publish.yml to the canonical push-by-digest + manifest-merge pattern: smoke test (amd64) runs on its own runner, each (variant x arch) push target runs on its own fresh runner with outputs=type=image,push-by-digest=true,push=true (no local image store), then a tiny merge job assembles the multi-arch manifest with docker buildx imagetools create from digest artifacts. Per-runner disk peak is roughly one-quarter of the old single-job peak. The four Docker Hub tags per release are unchanged. As a bonus, amd64 and arm64 now build in parallel. No image-level changes beyond the opencode bump. v1.14.31	2026-05-01 08:43:08 +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. v1.14.30b	2026-04-30 20:56:58 +00:00
joakimp	9d7c3e5ad8	Bump opencode to 1.14.30 v1.14.30	2026-04-30 15:11:49 +02: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. v1.14.29c	2026-04-29 15:27:30 +02:00
joakimp	e0b6c2082f	Add apt-get upgrade to core packages layer ... Pair 'apt-get upgrade -y --no-install-recommends' with the existing update + install in the first RUN step. Picks up security/CVE fixes that land in the Debian repos between base-image rebuilds. Same layer as the install to avoid bloating history; combined with apt-get clean and rm -rf /var/lib/apt/lists/* at the end so no index cache is kept. Today this is a no-op (debian:trixie-slim is current: 0 upgraded). Future-proofs against the lag between a CVE fix being published and the next base-image rebuild. v1.14.29b	2026-04-29 10:25:36 +02:00
joakimp	2c889b472e	Add --retry to all Dockerfile curl invocations ... The first v1.14.29b build attempt failed with an HTTP 502 from GitHub's release CDN mid-download of zoxide. Single-shot curl had no retry, so one transient 502 failed the entire OMOS build. - curl --retry 5 --retry-delay 5 --retry-all-errors on every tool download (both -fsSL GETs and -sI HEAD redirect lookups). - [ -n "$V" ] assertion after each version-resolution step, so a failed HEAD lookup fails fast with a clear message instead of producing an empty tag that then 404s on the download URL. - Same hardening applied to the optional Go install block and the nodesource setup_22.x pipe.	2026-04-29 10:14:42 +02:00