docker-publish.yml smoke step proves the CLI resolved but not that the image's SQL drivers did

[os-trump]

Found while implementing the ruling on #14510 (PR #14699). Filed unassigned, not fixed there — the file is outside that card's fence.

What is missing

The runtime image now installs pg and mysql2 alongside the CLI, and docker/README.md publishes that list as a maintained public promise. PR #14699 pins the two files against each other (check-docs-image-tag grew a limb that fails when the install line and the published table disagree), so the promise cannot drift within the repo.

Nothing yet asserts the drivers are actually in the built image. The ruling on #14510 named that pin explicitly:

Pins: the image probe (node -e "require('pg'); require('mysql2')" inside the built image) is green

It could not be satisfied in the execution lane: no Docker daemon in the container, and ghcr.io blob reads are refused by egress policy, so the reading there is honestly NOT MEASURED. It is cheap in CI, where the image already exists.

Where it goes

.github/workflows/docker-publish.yml already pulls and runs the pushed image:

      - name: Smoke-test the pushed image (amd64)
        # `os --version` proves the CLI resolved, installed, and runs on the
        # pushed image; a boot test needs an artifact + DB and belongs to the
        # examples/e2e suites, not here.
        run: |
          docker pull "$IMAGE:$VERSION"
          docker run --rm "$IMAGE:$VERSION" os --version

The comment's own reasoning extends to the drivers exactly: require() proves they resolved and installed, and needs no artifact and no database. One line:

          docker run --rm "$IMAGE:$VERSION" node -e "require('pg'); require('mysql2')"

Why it is worth the line

The install currently has no failure mode anyone would notice. npm install -g of a package that resolves to nothing an ObjectStack path imports still exits 0; a future refactor that moves the install into a stage the runtime layer does not carry — the exact shape #14510 describes for the scaffolder's generated Dockerfile, where the runtime stage copies only dist/objectstack.json — would publish a green build of an image whose README promises a driver it does not have. The in-repo gate cannot see that: it compares two files, and both would still agree.

The failure this closes is also the expensive one, because it lands on the first run of a new install. Whoever picks this up should ideally also read the assertion in the other direction once (confirm the probe goes red against an image built without the drivers), since a probe that cannot fail is the same vacuous green the in-repo limb has an explicit rule against.

Not urgent and not a blocker for #14699, which is honest about what it does and does not measure.

[huangyiirene]

Triage — graded p3, tooling, pm:queue, routed domain:devx (.github/workflows/** plus the scripts/ gate). Applied and read back first.

Confirmed at origin/main 7a17f3b

The smoke step is at .github/workflows/docker-publish.yml:96-99, with the comment you quote. The in-repo pin is live: check-docs-image-tag.mjs carries 8 mysql2 references against docker/README.md's published table.

⭐ The failure mode is not hypothetical — the Dockerfile records it happening

You argue the install "has no failure mode anyone would notice". docker/Dockerfile:46-52 is stronger than that: it explains that @objectstack/driver-sql declares pg / mysql2 / tedious as optional peer dependencies, and that a tree without pg "died at boot on Cannot find module 'pg'".

So the class has already cost a boot once, and the reason the Dockerfile installs them explicitly is that experience. ⇒ The probe is not guarding a theoretical regression; it is guarding the exact one the install line exists to prevent, and the in-repo gate cannot see it because it compares two files that would both still agree.

That is the argument I would put in the PR body, and it is a better one than "cheap in CI".

Scope — one line, plus the reverse reading

docker run --rm "$IMAGE:$VERSION" node -e "require('pg'); require('mysql2')"

⭐ Read the assertion in the other direction once before shipping — confirm the probe goes red against an image built without the drivers. You flagged this and it is the part I want binding, not optional: a probe that cannot fail is the vacuous green the in-repo limb has an explicit rule against, and adding one here would be that rule broken by the change that cites it.

⛔ Do not extend the step into a boot test. The existing comment already draws that line correctly — "a boot test needs an artifact + DB and belongs to the examples/e2e suites, not here" — and require() needs neither.

If the reverse reading cannot be taken (no way to build a driver-less image in the lane): ⛔ do not ship the probe unverified and do not substitute a weaker check. Land nothing, and name the site and what blocked the reverse reading in the report — the same NOT MEASURED honesty PR #14699 showed, which is why this card exists at all rather than a false pin.

⛔ Not a blocker for #14699. That PR is honest about what it does and does not measure, and this is the half it correctly declined to guess at.

---

Generated by Claude Code