Dev Container Features

This repository contains the pi-coding-agent Dev Container Feature for installing and configuring Pi inside a development container.

Features

• pi-coding-agent: Installs @earendil-works/pi-coding-agent with npm, installs bundled Pi extensions during feature setup, verifies the installation with pi --version, and can synchronize selected or all supported Pi configuration resources, including local Pi extensions, into the container at startup.

Usage

Pi is installed with npm, so the target dev container must already provide node and npm, either through its base image or through another feature that you add yourself. pi-coding-agent does not install Node.js on your behalf and fails fast if node or npm is absent.

{
	"image": "mcr.microsoft.com/devcontainers/javascript-node:4.0.10-24-bookworm",
	"features": {
		"ghcr.io/rodribus/devcontainer-features/pi-coding-agent:0": {
			"version": "latest"
		}
	}
}

To reuse Pi configuration from the host, mount a staging directory into the container and either opt into specific mappings or enable mapAllConfigurations. Mounting the full host ~/.pi/agent directory is the simplest option because it already matches the expected file layout, including extensions/ when you want to bring local Pi extensions into the container.

{
	"image": "mcr.microsoft.com/devcontainers/javascript-node:4.0.10-24-bookworm",
	"features": {
		"ghcr.io/rodribus/devcontainer-features/pi-coding-agent:0": {
			"configImportRoot": "/mnt/pi-coding-agent-import",
			"mapAllConfigurations": true,
			"sessionPersistenceMode": "volume"
		}
	},
	"mounts": [
		{
			"source": "${localEnv:HOME}/.pi/agent",
			"target": "/mnt/pi-coding-agent-import",
			"type": "bind"
		}
	]
}

When mapAllConfigurations is enabled, any individual map* options are ignored and the feature logs a warning. When sessionPersistenceMode is volume, the feature automatically provisions a per-devcontainer named volume for Pi sessions. When sessionPersistenceMode is bind, the feature points Pi at the bind-mounted storage path you provide instead of copying session files. Do not use the same live session storage from host Pi and container Pi at the same time.

Repository Layout

.
├── .devcontainer
├── .github/workflows
├── src/pi-coding-agent
└── test
	└── pi-coding-agent

Running Tests

All repository tests are run directly through the Dev Containers CLI. The authoring dev container already installs the CLI for you.

Run the full suite, including the autogenerated test.sh smoke test:

devcontainer features test --base-image mcr.microsoft.com/devcontainers/javascript-node:4.0.10-24-bookworm .

devcontainer features test --base-image mcr.microsoft.com/devcontainers/javascript-node:4.0.10-24-bookworm . runs the full repository test suite, including the autogenerated smoke test for pi-coding-agent and the hand-authored scenario coverage.

The explicit --base-image is needed because the autogenerated test.sh path installs pi-coding-agent in isolation. That smoke test needs a base image that already includes node and npm, but pi-coding-agent itself does not hard-depend on any Node feature.

Run the hand-authored scenario coverage plus the duplicate/idempotency check:

devcontainer features test --skip-autogenerated --base-image mcr.microsoft.com/devcontainers/javascript-node:4.0.10-24-bookworm .

devcontainer features test --skip-autogenerated --base-image mcr.microsoft.com/devcontainers/javascript-node:4.0.10-24-bookworm . skips every feature's autogenerated test.sh smoke test and still runs the scenario coverage plus duplicate-install coverage from each feature.

If you only want the scenario coverage and do not care about the duplicate-install check, you can also run:

devcontainer features test --skip-autogenerated --skip-duplicated .

That variant works with the repository's current scenarios because each scenario that installs pi-coding-agent also provisions node and npm explicitly.

The GitHub workflow currently uses the --base-image variant so it exercises both the autogenerated smoke test and the scenario suite.

If you are not using the authoring dev container, install the Dev Containers CLI first and then run the commands above directly.

Publishing

The release workflow publishes features from src/ to GHCR with devcontainers/action and generates feature README files. Enable GitHub Actions pull request creation in the repository settings before using the release workflow.