Docker Sandbox: Test and Playground

Use Docker sandbox when you want repeatable verification and a safe place to try commands without touching your host setup.

Mode Selection Diagram

Command mapping:

Shortcut	mise	make
test-docker	mise run test:docker	make test-docker
test-docker-online	mise run test:docker:online	make test-docker-online
sandbox-up	mise run sandbox:up	make sandbox-up
sandbox-shell	mise run sandbox:shell	make sandbox-shell
sandbox-down	mise run sandbox:down	make sandbox-down

What You Can Use It For

Mode	Best for	Network	Lifecycle
Offline test sandbox	Stable regression checks (build + unit + integration)	Disabled	One-shot
Online test sandbox	Optional remote install/update checks	Enabled	One-shot
Interactive playground	Manual command exploration and demos	Enabled	Persistent

---

Common Scenarios

1. Verify local install/update logic deterministically

Use this when you are changing install / update behavior and want a CI-like local gate.

mise run test:docker
make test-docker

This validates local-path and file:// workflows in isolation.

2. Run optional remote-source checks

Use this for GitHub/remote-source validation that depends on network access.

mise run test:docker:online
make test-docker-online

3. Open a dedicated playground and explore all commands

mise run sandbox:up
mise run sandbox:shell
make sandbox-up
make sandbox-shell

Inside the playground, skillshare and ss are ready:

skillshare --help
ss status
skillshare init --dry-run

When finished:

mise run sandbox:down
make sandbox-down

---

Why This Is Useful

• Reproducible: same base image, same toolchain, fewer machine-specific surprises.
• Safe isolation: test and experiment without polluting host-level paths.
• Fast iteration: separate offline/online modes let you keep default checks stable.
• Team onboarding: a shared command set (mise run ...) avoids setup drift.
• Tooling flexibility: use either mise or make, depending on team preference.

---

Practical Benefits by Role

• Maintainers: faster confidence for command-level changes.
• Contributors: one command to run the expected test gate.
• Power users: a disposable environment for trying risky workflows.
• Demo/training: predictable environment for live walkthroughs.

---

Limits and Expectations

• Offline sandbox cannot validate network-dependent features (for example remote install from GitHub).
• Playground uses container-local HOME, so it does not directly modify your real host home config.
• If you need custom experiments, pass commands directly:

./scripts/test_docker.sh --cmd "go test -v ./tests/integration/..."
./scripts/sandbox_playground_shell.sh "skillshare list"