# Per-recipe harness config for mumble (Phase 2 Q4.2 — a TCP/voice recipe, not HTTP-native).
#
# Mumble's voice server speaks its own TLS protocol on 64738 (no HTTP API). To fit cc-ci's
# HTTP-readiness + on-host test model we deploy two recipe overlays:
#   - compose.mumbleweb.yml  -> a mumble-web HTTP client routed through Traefik on the app domain,
#     giving the generic harness a real HTTP readiness/serving signal (HEALTH_PATH "/") AND the
#     web_client.py parity surface.
#   - compose.host-ports.yml -> publishes 64738 (tcp+udp) directly on the cc-ci host (mode: host).
#     Tests run on-host (cc-ci-run), so the protocol tests connect to 127.0.0.1:64738.
# Both overlays are shipped by the upstream recipe; this is a documented deployment mode, not a fork.
#
# Distinctive config markers (read back by the recipe-specific functional tests, proving our config
# actually propagated into the running server — version-independent, not hard-coded upstream values):
#   WELCOME_TEXT -> MUMBLE_CONFIG_WELCOMETEXT, surfaced in the ServerSync welcome_text.
#   USERS        -> MUMBLE_CONFIG_USERS (max users), surfaced in the ServerConfig.max_users.

HEALTH_PATH = "/"          # mumble-web client UI
HEALTH_OK = (200,)
DEPLOY_TIMEOUT = 900       # two images to pull (mumble-server + mumble-web) on a cold node
HTTP_TIMEOUT = 300

# A unique, stable welcome-text marker the round-trip test asserts surfaces over the protocol.
WELCOME_TEXT_MARKER = "cc-ci-mumble-welcome-7f3a9c"
# A distinctive max-users value (not the recipe default 100) the server_config test asserts.
MAX_USERS = 42

EXTRA_ENV = {
    "COMPOSE_FILE": "compose.yml:compose.mumbleweb.yml:compose.host-ports.yml",
    "WELCOME_TEXT": WELCOME_TEXT_MARKER,
    "USERS": str(MAX_USERS),
}