ci: a mongo image with an oplog, so CI can run the HA tests at all

[kzangeli]

What this is

quay.io/seamware/mongo-rs — mongo:8.0 with one thing changed, the command:

CMD ["mongod", "--replSet", "rs0", "--bind_ip_all"]

Why

The HA cache sync (--high-availability mongo) rides on a mongo change stream, and a change stream reads the oplog — which a standalone mongod does not have. coraine's harness knows this and detects it: corTestParams.sh probes isMaster.setName, and on a standalone ha_cache_sync.test leaves the run set.

Silently. Nothing in a CI log says the HA paths went unexercised, and every CI job has run a standalone mongo:8.0 since the workflows existed. Measured against today's coverage run, that is 108 lines and 10 functions of coraine that CI has never entered — which the nightly's published figure has been reporting as untested code rather than as an environment nobody stood up. doc/coverage.md says so in as many words; it was describing our own CI.

Why it needs an image

A GitHub Actions services: block passes docker-create options but not a command, so --replSet cannot be appended to mongo:8.0 from a workflow — and the job container has mongosh but no mongod of its own to start instead.

One member, because this is not a test of replication: it is the smallest thing that has an oplog.

What it deliberately does not do

Initiate the set. The member host has to be the name the clients use, and the image cannot know it — so rs.initiate() is one mongosh call in the consumer, beside the wait-for-database it already does. That half lands in the coraine PR.

Tagging

Same immutable <date>-<sha> as the other two, from the same run, so adopting a set of images stays one bump.

The verify step asserts the property consumers actually depend on: it comes up, it initiates, and isMaster then reports setName rs0 — the very probe the harness makes. Like the existing verify step, it is skipped on a PR, so this PR proves the Dockerfile builds and nothing more.

⚠️ Before merging

quay.io/seamware/mongo-rs does not exist. The robot seamware+coraine_ci has Write on coraine, coraine-ci and coraine-ci-nightly only, so the first push will 403 until:

1. the repo is created and made public (a service container is pulled anonymously), and
2. seamware+coraine_ci is granted Write on it.

Merging before that gives a red CI base image run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TGatXwrHx1CreL49sCuS37