secs-gem/docker-compose.yml

# 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]

  # A virtual fab: FAB_N secs_gemd equipment in one container (HSMS 5100+i,
  # gRPC 51000+i). interop/virtual_fab.py attaches a secsgem-py host AND a
  # secsgem_client tool to every one and drives seeded random traffic.
  fab:
    <<: *base
    depends_on:
      builder:
        condition: service_completed_successfully
    environment:
      FAB_N: "${FAB_N:-3}"
    command: ["bash", "tools/spawn_fab.sh"]
    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 (drive with `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: {}