mount compose workspace to container for update management

[kkroo]

No description provided.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: a4a6fc5

Critical Issues (1)

• [gstack/review] docker-compose.yml:9 — This change is superseded on main, and landing it would add a redundant mount at a container path nothing reads.
  • main already mounts a compose workspace for exactly this purpose: ${HOME}/.blockcast/compose:/etc/magma/compose (main docker-compose.yml:36), introduced in 265a5a5f0 ("autoupgrade") on 2025-09-25 — roughly three months after this PR's head commit (2025-07-02). Main's header comment now documents that dynamic services "are managed by blockcastd's compose_manager based on mconfig from controller", so the update-management consumer expects /etc/magma/compose, not /compose.
  • The PR also reports mergeable: CONFLICTING: main's compose file has been restructured from 35 lines to 91 and no longer resembles this branch's base.
  • Recommendation: close this PR as superseded, unless there is a consumer that specifically needs the invocation directory at /compose. If there is, rebase onto main and justify it against the existing /etc/magma/compose mount rather than adding a second one.

Important Issues (2)

• [native-codex] docker-compose.yml:9 — ${PWD} is the caller's working directory, not the compose project directory, so this can silently mount the wrong tree.

  • Compose interpolates ${PWD} from the process environment; it is not a Compose-defined variable and has no relationship to the compose file's location. docker compose -f /opt/blockcast/docker-compose.yml up -d run from $HOME mounts $HOME at /compose. There is no error — the container just gets the wrong directory, which is a bad failure mode for something that manages updates. The README's documented flow (docker compose up -d from the checkout) happens to make these coincide, which is why this is easy to miss.
  • Recommendation: use - .:/compose. Relative host paths in volumes are resolved against the project directory, which is what "compose workspace" actually means here. A stable absolute path (as main uses) is equally fine.

• [pr-review-toolkit/errors] docker-compose.yml:9 — an unset PWD degrades to a malformed volume spec rather than a clear failure.

  • Non-shell parents (systemd units, cron, some CI runners) do not export PWD. Compose interpolates an unset variable to the empty string, so the spec becomes :/compose, which fails to parse — startup breaks rather than falling back. For a node/beacon product that is plausibly supervisor-started at boot, that is a realistic path. Lines 6–7 share this fragility with ${HOME}, but those are pre-existing; this adds a new instance of it.
  • Recommendation: same fix as above — a relative or fixed path removes the dependency on ambient environment entirely.

Suggestions (2)

• [pr-review-toolkit/code] docker-compose.yml:9 — the mount is added to the shared x-service anchor, so all three services (control_proxy, blockcastd, beacond) receive it, although only the update-management path needs it. Consider attaching it to the specific service instead, and mounting :ro if the consumer only reads the compose file. (Note the blast radius here is bounded: every one of these services already mounts /var/run/docker.sock at line 8, which is root-equivalent on the host — so this is a least-privilege tidiness point, not a new escalation.)
• [pr-review-toolkit/tests] repo-level — there is no CI check running docker compose config on this file. A one-line validation job in a clean environment would have caught the empty-PWD case in the finding above, and is cheap for a compose-only repo.

Strengths

• Tightly scoped, single-purpose diff — one file, one behavioral line.
• Cleans up the trailing whitespace on line 8 while touching that block.
• The underlying goal was sound and was independently confirmed as the right direction: main adopted a compose-workspace mount for update management three months later.

Recommended Action

1. Treat the Critical as a merge decision, not a code fix: confirm against main's /etc/magma/compose mount whether this PR still has a purpose, and close it as superseded if not.
2. If it is still wanted, rebase onto main (currently conflicting) and replace ${PWD} with a project-relative or fixed path before landing.
3. Consider the scoping and docker compose config suggestions opportunistically.