Minimal YottaDB Docker container for m-cli and m-stdlib testing.

Provides a long-running m-test-engine container exposing a YottaDB engine via docker exec. Consumers are m-cli's DockerEngine transport and m-stdlib's test runner — both dispatch on docker exec m-test-engine $ydb_dist/mumps -run ....

m-cli and m-stdlib previously bound their test runners to vista-meta — a heavyweight YottaDB + VistA + RPC broker + FileMan + Octo SQL stack. For non-VistA M development, that's overkill: the tests just need a YottaDB engine.

m-test-engine is exactly that — yottadb/yottadb-base:latest-master with a keep-alive command. No SSH server, no VistA, no extras. All participating m-* repos live under $HOME/m-work on the host (clones or symlinks) and the container bind-mounts that single directory as /m-work, so every repo's routines are simultaneously visible inside one running engine — no per-cwd remount, no SCP / staging round-trip.

For VistA-specific work, keep using vista-meta. This repo is the lightweight default for the rest of the toolchain.

git clone https://github.com/m-dev-tools/m-test-engine ~/projects/m-test-engine
cd ~/projects/m-cli         # or wherever your consumer project lives
make -C ~/projects/m-test-engine up

m-cli auto-detects the running container if no other engine is configured (M_CLI_ENGINE env var unset, no vista-meta conn.env):

m test            # runs against m-test-engine via DockerEngine

To force the Docker transport explicitly:

M_CLI_ENGINE=docker m test

Run any of those from this repo's root.

m-cli's DockerEngine (in src/m_cli/engine.py) issues commands of the form:

docker exec m-test-engine bash -lc \
    'export ydb_routines="<stage> $ydb_dist" && exec $ydb_dist/mumps -run ^<SUITE>'

The <stage> is the in-container path to the consumer project's routine dirs — derived by mapping the project root through the shared /m-work bind mount. There's no SCP / SFTP step: every m-* repo's filesystem is directly visible inside the container.

m-stdlib's test runner uses the same transport once Track A3 of the m-dev-tools-todo plan lands.

dist/m-test-engine.json is the canonical machine-readable contract between this repo and its consumers (primarily m-cli's m doctor and the upcoming m engine subcommand family). It declares the image registry, default tag, container name, bind-mount layout, compose file path, minimum Docker version, YottaDB release, and a run_args block sufficient to reconstruct an equivalent docker run invocation when the compose plugin is unavailable.

The schema lives alongside it at dist/m-test-engine.schema.json. make check-manifest validates both dist/repo.meta.json and dist/m-test-engine.json — schema-shape, compose_file resolves on disk, and verified_on is within 90 days.

Consumers vendor dist/m-test-engine.json at release time (m-cli pins to a tagged release of this repo). The protocol bump policy and the broader integration design are recorded in docs/m-engine-implementation-plan.md.

The default container has no SSH server. For consumers still using m-cli's legacy SSHEngine transport (e.g. matching the vista-meta contract), add a compose.ssh.yml overlay layering an openssh-server install on top of the base image. Not shipped here — file an issue or PR if you need it.

AGPL-3.0 — parity with the rest of the m-dev-tools toolchain repos.