Acceptance testing guide: cover running Beaker inside a container (VoxBox/CI sibling containers)

[miharp]

The acceptance testing guide assumes Beaker runs on the host machine. When Beaker itself runs inside a container (for example VoxBox in a CI job) with the test containers as siblings on a shared network, beaker-docker's default connection logic picks 127.0.0.1:<mapped port>, which points at the wrong container: the connection hangs for a long time and then falls back to an unresolvable hostname. This came up in Slack and cost a user half an hour of head-scratching per run.

Verified behavior (beaker 7.6.0, beaker-docker 3.1.2, reproduced locally with a sibling runner container):

• Docker: setting DOCKER_IN_DOCKER=true makes Beaker connect directly to each test container's network IP. Works out of the box.
• Podman 5: the same flag crashes with a NoMethodError in get_ssh_connection_info, because Podman's Docker-compatible API keys NetworkSettings.Networks by the real network name while reporting HostConfig.NetworkMode as bridge. Tracked upstream in DOCKER_IN_DOCKER=true crashes with NoMethodError on Podman 5: Networks[NetworkMode] lookup assumes Docker's network naming voxpupuli/beaker-docker#192 (fix drafted).

The guide should:

• Explain the sibling-container scenario and document DOCKER_IN_DOCKER=true for Docker
• Warn that Podman 5 currently crashes with current beaker-docker, pointing at DOCKER_IN_DOCKER=true crashes with NoMethodError on Podman 5: Networks[NetworkMode] lookup assumes Docker's network naming voxpupuli/beaker-docker#192
• Once a fixed beaker-docker release exists, replace the warning with the minimum working version

A draft of the note (first two bullets) already exists locally and will come in as a PR.

---

Investigated and drafted with the assistance of Claude Code (reviewed by a human before filing).