Skip to content

Add containerized full-suite profiles for controller and P2P client testing

Summary

Add supported full-suite test profiles that launch isolated Docker containers for controller and peer-client dependencies used by eMuleBB live E2E proof. The goal is repeatable local release and regression evidence without relying on host-installed Arr services, qBittorrent, aMule, aMuTorrent, or p2p-overlord state.

This is test infrastructure. It must be wired through the supported repos\emulebb-build orchestration entrypoints rather than ad hoc direct Docker commands in app-source workflows.

Target Profiles

  • Arr controller stack profile covering the supported Sonarr, Radarr, and Prowlarr eMuleBB integration lanes.
  • aMuTorrent controller profile with isolated browser, server, and profile state.
  • aMule compatibility-client profile for local ED2K interoperability and mixed-client behavior checks.
  • p2p-overlord product-family profile for scenario and controller integration coverage.
  • qBittorrent-compatible controller profile for qBit API/session behavior and adapter parity checks.
  • Full-suite aggregate profile that composes the above with eMuleBB host profiles and deterministic local services.

Constraints

  • Default runs must stay local live-stack tests: no public eD2K/Kad bootstrap, public searches, or public peer discovery unless a profile is explicitly marked as public-network proof and follows the live-test network policy.
  • Use isolated Docker networks, volumes, ports, and profile roots per run so suites cannot leak state across attempts.
  • Mixed-client runs that include aMule must keep generated profile, incoming, temp, and shared-library paths short enough for compatibility clients.
  • eMuleBB remains the Windows host app under test unless a future supported container runner exists for the app itself.
  • Container images must be pinned or provenance-recorded so release evidence is reproducible.
  • Runtime secrets, API keys, and generated credentials must be per-run artifacts and must not be committed.

Intended Shape

  1. Add a workspace-owned Docker Compose or equivalent profile definition for each target dependency family.
  2. Add orchestration support in emulebb-build for creating, health-checking, and tearing down the container set.
  3. Teach live E2E profiles to consume generated service endpoints and credentials from the orchestration layer.
  4. Capture container image digests, logs, ports, health states, and teardown status in the existing test-report artifact tree.
  5. Add a full-suite profile that composes Arr, aMuTorrent, aMule, p2p-overlord, qBittorrent, local ED2K service, and eMuleBB host profiles.

Acceptance Criteria

  • [ ] A supported orchestration command can launch and tear down each container profile without manual host setup.
  • [ ] Each profile uses per-run isolated network, volume, port, and credential state.
  • [ ] Existing Arr, aMuTorrent, qBit-compatible, and local ED2K live tests can consume container-provided endpoints.
  • [ ] aMule mixed-client runs use short profile/storage paths and do not become long-path proof targets.
  • [ ] p2p-overlord scenarios can run against the same deterministic local stack and publish artifacts next to the eMuleBB report.
  • [ ] Full-suite reports record image provenance, container logs, health checks, eMuleBB profile paths, child-suite results, and teardown outcome.
  • [ ] Public-network behavior remains opt-in and separately labeled.

Validation

  • python -m emule_workspace validate
  • Focused Python tests for profile generation, port allocation, credential wiring, and teardown behavior.
  • Focused live E2E run for each individual container profile.
  • Full-suite live E2E run using only deterministic local services.