raphael
b30443089f
tests / build-and-test (push) Successful in 2m54s
tests / thread-sanitizer (push) Successful in 3m48s
tests / tshark-dissector (push) Successful in 2m24s
tests / secs4j-interop (push) Successful in 1m44s
tests / python-interop (push) Successful in 3m10s
tests / libfuzzer (push) Successful in 3m38s
B7 — the daemon's HSMS face under the Java reference: Dockerfile.server now
bakes secs_gemd alongside secs_server (grpc deps in both stages), and
secs4j_validate.sh gains TARGET=gemd to point the 55-check secs4java8 suite
at the daemon instead. Result: 55/55 green. With secsgem-py already
validating both faces, byte-identical GEM between secs_server and secs_gemd
is now proven by both reference implementations, not inferred from shared
code. CI runs the daemon target as an extra step (image layers shared).
Second client — clients/cpp: a header-only C++ twin of the Python client
over the same proto. eq.set("ChamberPressure", 2.5) with bare literals
(integral/floating dispatch avoids variant ambiguity), get/fire/alarm/
clear, control_state/request_control_state/health, on("START", fn) +
listen()/listen_async()/stop() with auto-CompleteCommand, SecsGemError
carrying the daemon's message. cpp_mini_tool (~30 lines) mirrors the
Python mini_tool. Tested end-to-end over real loopback TCP against the
service inside secs_gemd_tests — now 4 cases / 141 assertions — including
set/get round-trips, error text, alarm-by-name into the model, health,
and the full HCACK-4 command loop with parameters.
(Build note: two grpc-heavy TUs at -O3 OOM even at -j2 on Docker Desktop;
built -j1. Known environment limitation, roadmap-documented.)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
50 lines
2.0 KiB
Docker
50 lines
2.0 KiB
Docker
# Self-contained secs_server image for the secs4j interop harness.
|
|
#
|
|
# The dev-time `server` compose service bind-mounts the source tree
|
|
# read-write at /app and lets the in-container `builder` step compile
|
|
# there. That works on a developer laptop but breaks under docker-
|
|
# in-docker (gitea-act / GitHub Actions runners with a mounted
|
|
# /var/run/docker.sock): the bind-mount source resolves against the
|
|
# *host* daemon's filesystem, not the runner container's, so /app
|
|
# mounts empty and the build / launch silently fails.
|
|
#
|
|
# This image bakes the source + Release binary in at build time so
|
|
# `docker run` of it needs no volumes at all — same pattern already
|
|
# used by interop/secs4j/Dockerfile for the Java harness.
|
|
FROM ubuntu:24.04 AS build
|
|
|
|
ENV DEBIAN_FRONTEND=noninteractive
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
build-essential cmake ninja-build \
|
|
libasio-dev libyaml-cpp-dev \
|
|
libprotobuf-dev protobuf-compiler protobuf-compiler-grpc libgrpc++-dev \
|
|
python3 python3-yaml \
|
|
git ca-certificates \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
|
|
WORKDIR /src
|
|
COPY . /src
|
|
RUN cmake -S /src -B /src/build -G Ninja -DCMAKE_BUILD_TYPE=Release \
|
|
&& cmake --build /src/build --target secs_server secs_gemd
|
|
|
|
|
|
FROM ubuntu:24.04
|
|
|
|
ENV DEBIAN_FRONTEND=noninteractive
|
|
# Dev packages in the runtime layer purely to pull the grpc/protobuf
|
|
# runtime libs by reliable names; image size is irrelevant for a CI harness.
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
libyaml-cpp0.8 libgrpc++-dev libprotobuf-dev \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
|
|
# WORKDIR must be the directory holding `data/` because secs_server's
|
|
# default --config / --state-table paths are relative ("data/...").
|
|
WORKDIR /app
|
|
COPY --from=build /src/build/secs_server /usr/local/bin/secs_server
|
|
COPY --from=build /src/build/secs_gemd /usr/local/bin/secs_gemd
|
|
COPY data /app/data
|
|
|
|
EXPOSE 5000
|
|
ENTRYPOINT ["/usr/local/bin/secs_server"]
|
|
CMD ["--port", "5000", "--device", "0"]
|