joakimp
f51e9f52a1
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.
95 lines
4.5 KiB
Bash
95 lines
4.5 KiB
Bash
# opencode-devbox environment configuration
|
|
# Copy this file to .env and fill in your values:
|
|
# cp .env.example .env
|
|
|
|
# ── LLM Provider ─────────────────────────────────────────────────────
|
|
# Which provider to auto-configure (anthropic, openai, amazon-bedrock)
|
|
OPENCODE_PROVIDER=anthropic
|
|
|
|
# Model override (optional, defaults per provider)
|
|
# OPENCODE_MODEL=anthropic/claude-sonnet-4-6
|
|
|
|
# ── API Keys (set the one matching your provider) ────────────────────
|
|
# ANTHROPIC_API_KEY=
|
|
# OPENAI_API_KEY=
|
|
# GEMINI_API_KEY=
|
|
|
|
# ── AWS Bedrock (if using amazon-bedrock provider) ───────────────────
|
|
# AWS_REGION=eu-west-1
|
|
# AWS_PROFILE=default
|
|
# AWS_ACCESS_KEY_ID=
|
|
# AWS_SECRET_ACCESS_KEY=
|
|
|
|
# ── Git Configuration ────────────────────────────────────────────────
|
|
GIT_USER_NAME=
|
|
GIT_USER_EMAIL=
|
|
|
|
# ── Workspace ────────────────────────────────────────────────────────
|
|
# Path on host to mount as /workspace in the container
|
|
WORKSPACE_PATH=~/projects
|
|
|
|
# Path to SSH keys on host
|
|
SSH_KEY_PATH=~/.ssh
|
|
|
|
# ── Skillset (agent skills and instructions) ─────────────────────────
|
|
# If you have a skillset repo, the entrypoint auto-deploys skills and
|
|
# instructions on container start using relative symlinks (portable
|
|
# across host/container).
|
|
#
|
|
# Detection is automatic if the skillset lives directly at the workspace
|
|
# root (i.e. WORKSPACE_PATH/skillset → /workspace/skillset in container).
|
|
#
|
|
# If the skillset lives in a subdirectory of your workspace, set
|
|
# SKILLSET_CONTAINER_PATH to its location *inside the container*. This
|
|
# is determined by the workspace mount: whatever is at
|
|
# WORKSPACE_PATH/<subpath> on the host becomes /workspace/<subpath>
|
|
# in the container.
|
|
#
|
|
# Examples:
|
|
# Host skillset at ~/projects/skillset → already at /workspace/skillset (auto-detected, no config needed)
|
|
# Host skillset at ~/projects/tools/skillset → SKILLSET_CONTAINER_PATH=/workspace/tools/skillset
|
|
# Host skillset at ~/projects/local/skillset → SKILLSET_CONTAINER_PATH=/workspace/local/skillset
|
|
#
|
|
# Alternatively, mount the skillset repo at a dedicated path using the
|
|
# SKILLSET_PATH volume in docker-compose.yml (see comments there). In
|
|
# that case the entrypoint finds it at ~/skillset automatically.
|
|
#
|
|
# SKILLSET_CONTAINER_PATH=
|
|
|
|
# ── Locale (defaults to en_US.UTF-8) ─────────────────────────────────
|
|
# LANG=sv_SE.UTF-8
|
|
# LANGUAGE=sv_SE:sv
|
|
# LC_ALL=sv_SE.UTF-8
|
|
|
|
# ── oh-my-opencode-slim (multi-agent orchestration) ──────────────────
|
|
# Requires image built with INSTALL_OMOS=true
|
|
# ENABLE_OMOS=false
|
|
# OMOS_TMUX=false # Enable tmux multiplexer integration
|
|
# OMOS_SKILLS=true # Install recommended skills (simplify, agent-browser, cartography)
|
|
# OMOS_RESET=false # Force regenerate oh-my-opencode-slim config on next start
|
|
|
|
# ── pi coding-agent (alternative/complementary harness) ─────────────────
|
|
# Requires image built with INSTALL_PI=true.
|
|
# When the image is built with both INSTALL_OPENCODE=true (default) and
|
|
# INSTALL_PI=true, both harnesses share the same mempalace install and
|
|
# palace path — wing data is mutually visible to either harness.
|
|
#
|
|
# Pi version is baked at build time via PI_VERSION (default: latest at
|
|
# build). `pi update` inside the container would write to the npm global
|
|
# prefix, which is not on a named volume — updates do not persist across
|
|
# `--rm` containers. Rebuild the image to upgrade pi.
|
|
#
|
|
# Pi config (settings.json, extensions toggle state) persists in the
|
|
# devbox-pi-config named volume mounted at ~/.pi/.
|
|
#
|
|
# To launch pi from a `compose run` invocation:
|
|
# docker compose run --rm devbox pi
|
|
# To attach to a running container:
|
|
# docker compose exec -u developer devbox pi
|
|
# Default `compose run` (no args) drops to bash; pick the harness yourself.
|
|
#
|
|
# Build args (set in docker-compose.yml or via --build-arg on docker build):
|
|
# INSTALL_PI=true # default false; opt-in
|
|
# PI_VERSION=latest # pin a specific version, e.g. 0.73.0
|
|
# INSTALL_OPENCODE=false # build a pi-only image (still has Bun in -omos)
|