Files
secs-gem/docker-compose.yml
T
raphael 3d72e50b65 test(interop): daemon end-to-end vs secsgem-py reference host
daemon_interop.py drives a running secs_gemd through BOTH faces at once: a
gRPC tool client and a secsgem-py active host. Proves the gRPC<->HSMS bridge
against a reference GEM implementation, not just in-process:

  - gRPC GetControlState agrees with the HSMS-driven control state
  - gRPC SetVariables(ChamberPressure=2.5) + FireEvent(ProcessStarted) makes
    the host receive S6F11 CEID 300 carrying 2.5 (value flowed gRPC -> engine
    -> HSMS -> host)
  - unknown variable/event names rejected at the gRPC edge

Mirrors the existing host_vs_cpp_server.py pattern. New 'gemd' compose service
(HSMS :5000 + gRPC :50051); interop image gains grpcio/grpcio-tools (proto
stubs generated at runtime, flat to avoid the secsgem package-name clash).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 18:23:47 +02:00

124 lines
3.4 KiB
YAML

# All build artifacts live in the named `build` volume (inside Docker), the
# host only provides the source tree mounted read-write at /app.
#
# docker compose build # build the toolchain image
# docker compose run --rm builder # configure + compile
# docker compose run --rm tests # run unit tests
# docker compose up server client # live HSMS demo
x-base: &base
build: .
volumes:
- .:/app
- build:/app/build
services:
builder:
<<: *base
# Put builder on the same network as server/client/equipment_py so
# one-off `docker compose run --rm builder /app/build/secs_interop_probe ...`
# commands can DNS-resolve peer services by their compose name.
networks: [secs]
command:
- bash
- -lc
- >
cmake -S /app -B /app/build -G Ninja -DCMAKE_BUILD_TYPE=Release &&
cmake --build /app/build
tests:
<<: *base
depends_on:
builder:
condition: service_completed_successfully
command: ["ctest", "--test-dir", "/app/build", "--output-on-failure"]
server:
<<: *base
depends_on:
builder:
condition: service_completed_successfully
command: ["/app/build/secs_server", "--port", "5000", "--device", "0"]
networks: [secs]
# No host port publish: the client reaches the server over the `secs`
# Docker network by service name. Uncomment to expose to the host.
# ports:
# - "5000:5000"
client:
<<: *base
depends_on:
builder:
condition: service_completed_successfully
server:
condition: service_started
command: ["/app/build/secs_client", "--host", "server", "--port", "5000", "--device", "0"]
networks: [secs]
# The gRPC daemon: passive HSMS equipment on :5000 plus the gRPC tool API
# on :50051. Used by interop/daemon_interop.py (a gRPC tool + a secsgem-py
# host both drive it) to prove the gRPC<->HSMS bridge against a real host.
gemd:
<<: *base
depends_on:
builder:
condition: service_completed_successfully
command:
- /app/build/secs_gemd
- --port
- "5000"
- --grpc
- "0.0.0.0:50051"
- --config-dir
- /app/data
networks: [secs]
# Python container preloaded with secsgem-py 0.3.0 for cross-validation
# of our C++ HSMS/SECS-II/GEM implementation against the reference library.
interop:
build: ./interop
volumes:
- .:/app
working_dir: /app/interop
networks: [secs]
# secsgem-py running as passive equipment so the C++ active host can
# connect to it. Used by tools/run_interop.sh which then launches
# `secs_interop_probe --host equipment_py`.
equipment_py:
build: ./interop
volumes:
- .:/app
working_dir: /app/interop
command: ["python3", "/app/interop/passive_equipment.py", "--port", "5000"]
networks: [secs]
# Server variant for the persistent-spool restart test. Identical to
# `server` but with --spool-dir pointed at a named volume so spooled
# messages survive `docker compose restart server-spool`.
server-spool:
<<: *base
depends_on:
builder:
condition: service_completed_successfully
command:
- /app/build/secs_server
- --port
- "5000"
- --device
- "0"
- --spool-dir
- /spool
volumes:
- .:/app
- build:/app/build
- spool:/spool
networks: [secs]
networks:
secs: {}
volumes:
build: {}
spool: {}