recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(mumble F2-14c): drop cc-ci compose.host-ports.yml fork; deploy 0.2.0 base minimally, add native host-ports on upgrade-to-latest via new UPGRADE_EXTRA_ENV harness hook + COMPOSE_FILE-aware READY_PROBE/install skip

Browse Source
This commit is contained in:
autonomic-bot
2026-05-31 05:07:44 +00:00
parent e3720bedf3
commit 4bf9e1d43d
8 changed files with 101 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
tests/mumble/recipe_meta.py
View File

@ -1,28 +1,33 @@
# 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:
# HTTP-readiness + on-host test model we deploy upstream 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.
# web_client.py parity surface. Shipped upstream from 0.1.0 (present on the 0.2.0 base too).
# - compose.host-ports.yml -> publishes 64738 (tcp+udp, mode:host) on the cc-ci host so on-host
# tests (cc-ci-run) reach the voice server at 127.0.0.1:64738. Shipped upstream ONLY from 1.0.0.
#
# F2-14c disposition (Adversary REVIEW-2 @16:22:07Z VETO): the upgrade tier's base is the previous
# published version 0.2.0+v1.6.870-0, which PREDATES compose.host-ports.yml (added in 1.0.0). We do
# NOT carry a cc-ci copy of that upstream overlay (no fork). Instead:
# - the BASE 0.2.0 deploys MINIMALLY with `compose.yml:compose.mumbleweb.yml` (HTTP health via
# mumble-web works; the voice port is NOT host-published on 0.2.0), and the on-host voice/protocol
# custom tests are SKIPPED on 0.2.0 (they run in the CUSTOM tier, which executes once on the
# post-upgrade LATEST);
# - the UPGRADE to latest (1.0.0+, which ships compose.host-ports.yml NATIVELY) adds host-ports to
# COMPOSE_FILE via UPGRADE_EXTRA_ENV (applied by generic.perform_upgrade after the PR-head
# checkout, before the chaos redeploy), so the voice port IS host-published on latest and the
# voice tests run there. The current version's native overlay is untouched (no cc-ci 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_PATH = "/" # mumble-web client UI (present on both 0.2.0 base and 1.0.0 latest)
HEALTH_OK = (200,)
# install_steps.sh provides compose.host-ports.yml to recipe versions that predate it (the upgrade
# tier's base deploy is the previous published version, 0.2.0+, which lacks the upstream overlay).
# That untracked file makes abra's PINNED base-deploy clean-tree check FATA, so deploy the
# explicitly-checked-out pinned version with chaos (skips lint/clean-tree; deploys the version, not
# LATEST). No-op for the upgrade tier (already a PR-head chaos redeploy). See DECISIONS.md.
CHAOS_BASE_DEPLOY = True
DEPLOY_TIMEOUT = 900 # two images to pull (mumble-server + mumble-web) on a cold node
HTTP_TIMEOUT = 300
@ -31,19 +36,34 @@ 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
# BASE deploy (0.2.0): mumble-web only — NO host-ports (0.2.0 predates it). The voice-config env is
# set here and persists across the upgrade so it takes effect on the latest (where the custom config
# round-trip tests assert it).
EXTRA_ENV = {
"COMPOSE_FILE": "compose.yml:compose.mumbleweb.yml:compose.host-ports.yml",
"COMPOSE_FILE": "compose.yml:compose.mumbleweb.yml",
"WELCOME_TEXT": WELCOME_TEXT_MARKER,
"USERS": str(MAX_USERS),
}
# UPGRADE-target deploy (latest 1.0.0+): add the NATIVE compose.host-ports.yml so 64738 is
# host-published and the on-host voice/protocol custom tests can run on latest.
UPGRADE_EXTRA_ENV = {
"COMPOSE_FILE": "compose.yml:compose.mumbleweb.yml:compose.host-ports.yml",
}
def READY_PROBE(domain):
# HEALTH_PATH "/" only proves the mumble-web HTTP sidecar; it does NOT reflect the voice server.
# After a chaos upgrade redeploy the host-mode 64738 port must be released by the old task and
# rebound by the new one — a window where the app (voice) container isn't yet serving while
# mumble-web still returns 200. backup-bot then execs its sqlite pre-hook into a not-running app
# container → 409. Gate readiness on the voice port being STABLY listening (3 consecutive
# connects) before the harness proceeds to the backup tier. The port is host-published
# (compose.host-ports.yml), so we probe it on the cc-ci host where the run executes.
return [{"tcp_host": "127.0.0.1", "tcp_port": 64738, "stable": 3}]
# The voice server on 64738 is testable on-host ONLY when compose.host-ports.yml is active — i.e.
# the post-upgrade LATEST, not the minimal 0.2.0 base. Read the live COMPOSE_FILE to decide, so the
# SAME probe fn is correct in both phases: the post-install probe (base, no host-ports) returns []
# (HTTP health alone gates the base), the post-upgrade probe (latest, host-ports) gates readiness
# on the voice port being STABLY listening (3 consecutive connects) before the harness proceeds to
# backup — after the chaos upgrade redeploy the host-mode 64738 must be released by the old task and
# rebound by the new one (a window where mumble-web 200s while the voice container isn't yet up, and
# backup-bot would then exec into a not-running app container -> 409).
from harness import abra # lazy: recipe_meta is exec'd with `harness` importable at call time
cf = abra.env_get(domain, "COMPOSE_FILE") or ""
if "compose.host-ports.yml" in cf:
return [{"tcp_host": "127.0.0.1", "tcp_port": 64738, "stable": 3}]
return []