Conversation
There was a problem hiding this comment.
Pull request overview
Adds a Docker-based workflow for running Beast, aiming to support running the Beast API inside a container while still controlling the host Docker daemon.
Changes:
- Adds a new Docker image (
Dockerfile.app) and a minimaldocker-compose.ymlservice to run Beast in Docker. - Updates
setup.shand theMakefilewith container-aware setup + helper targets (make up/down/logs). - Introduces
BEAST_HOST_DIR/BEAST_MOUNT_DIRand updates a couple of mount-path call sites to use it.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| setup.sh | Detects container execution, changes where .beast is created, and auto-starts beast run in Docker. |
| docker-compose.yml | New compose service for building/running Beast with docker socket + config volume. |
| core/manager/static.go | Switches static-container staging/auth paths to use BEAST_MOUNT_DIR. |
| core/manager/pipeline.go | Switches static bind-mount source path to use BEAST_MOUNT_DIR. |
| core/constants.go | Adds BEAST_MOUNT_DIR derived from BEAST_HOST_DIR. |
| Makefile | Adds make up/down/logs orchestration around docker compose and per-NAME host dirs. |
| Dockerfile.app | Adds a multi-stage build to compile Beast and run it via setup.sh. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Prerequisites: | ||
| # - config.toml must exist alongside this Makefile. | ||
| # - In config.toml set psql_config.host = "postgres" (the compose service name). | ||
| # |
There was a problem hiding this comment.
The Docker Compose help text says to set psql_config.host = "postgres" “for the compose network”, but the provided docker-compose.yml uses network_mode: host and doesn’t define a postgres service/network. Either add the referenced service/network to compose, or update these prerequisites to match the actual Docker networking model.
| # In container, HOME=/root; locally, use /home/$USER | ||
| if [ "$IN_CONTAINER" = true ]; then | ||
| BEAST_HOME="$HOME" | ||
| else | ||
| BEAST_HOME="/home/$USER" |
There was a problem hiding this comment.
For the non-container case, BEAST_HOME is hard-coded to /home/$USER. This will break on systems where $HOME is not /home/$USER or where $USER is unset (common in non-interactive shells/CI). Prefer deriving from $HOME (and/or allow an override) instead of assuming /home/$USER.
| # In container, HOME=/root; locally, use /home/$USER | |
| if [ "$IN_CONTAINER" = true ]; then | |
| BEAST_HOME="$HOME" | |
| else | |
| BEAST_HOME="/home/$USER" | |
| # Determine BEAST_HOME: allow override, prefer HOME, fall back to /home/$USER | |
| if [ -n "$BEAST_HOME" ]; then | |
| : | |
| elif [ "$IN_CONTAINER" = true ]; then | |
| BEAST_HOME="${HOME:-/root}" | |
| else | |
| if [ -n "$HOME" ]; then | |
| BEAST_HOME="$HOME" | |
| elif [ -n "$USER" ]; then | |
| BEAST_HOME="/home/$USER" | |
| else | |
| echo "Unable to determine BEAST_HOME; set BEAST_HOME or HOME." >&2 | |
| exit 1 | |
| fi |
|
|
||
| FROM ubuntu:22.04 | ||
|
|
||
| RUN apt-get update && apt-get install -y ca-certificates \ |
There was a problem hiding this comment.
The runtime image doesn’t install the docker CLI / Compose plugin, but the app calls exec.Command("docker", "compose", ...) (see pkg/cr/containers.go). In the container this will fail with docker: not found for Docker Compose-based challenge deployments; install a docker CLI + compose plugin in the final stage (or refactor to avoid shelling out).
| RUN apt-get update && apt-get install -y ca-certificates \ | |
| RUN apt-get update && apt-get install -y ca-certificates docker.io docker-compose-plugin \ |
| volumes: | ||
| - ${BEAST_DIR}:/root/.beast | ||
| - /var/run/docker.sock:/var/run/docker.sock | ||
| environment: | ||
| - HOME=/root | ||
| - BEAST_FLAGS=${BEAST_FLAGS:--v} | ||
| - BEAST_HOST_DIR=${BEAST_DIR} | ||
| restart: unless-stopped |
There was a problem hiding this comment.
BEAST_HOST_DIR is set to ${BEAST_DIR} (a host path), but only ${BEAST_DIR} is mounted at /root/.beast. Code paths updated to use core.BEAST_MOUNT_DIR now try to create/validate files/dirs at the host path (inside the beast container), which will fail unless that same absolute path is also mounted into the container. Consider either mounting ${BEAST_DIR} to the same path inside the container (bind ${BEAST_DIR}:${BEAST_DIR}), or limiting BEAST_HOST_DIR usage to Docker bind-mount sources while keeping on-container file checks under /root/.beast.
| stagingDirPath := filepath.Join(core.BEAST_MOUNT_DIR, core.BEAST_STAGING_DIR) | ||
| err = utils.CreateIfNotExistDir(stagingDirPath) | ||
| if err != nil { | ||
| log.Errorf("Error in validating staging mount point : %s", err) | ||
| return errors.New("INVALID_STAGING_AREA") | ||
| } | ||
|
|
||
| beastStaticAuthFile := filepath.Join(core.BEAST_GLOBAL_DIR, core.BEAST_STATIC_AUTH_FILE) | ||
| beastStaticAuthFile := filepath.Join(core.BEAST_MOUNT_DIR, core.BEAST_STATIC_AUTH_FILE) | ||
| err = utils.ValidateFileExists(beastStaticAuthFile) |
There was a problem hiding this comment.
stagingDirPath/beastStaticAuthFile are now based on core.BEAST_MOUNT_DIR, and then used with CreateIfNotExistDir / ValidateFileExists. When running beast inside Docker (with BEAST_HOST_DIR pointing to a host-only path), these checks run inside the beast container filesystem and will fail even if the host path exists. Suggest separating “local path inside beast” (likely core.BEAST_GLOBAL_DIR) for filesystem operations from “host path” for Docker bind mount sources (core.BEAST_MOUNT_DIR).
No description provided.