Skip to content

issue_71: Let the container engine be named explicitly - #72

Merged
dieterbaier merged 1 commit into
mainfrom
issue_71
Jul 29, 2026
Merged

issue_71: Let the container engine be named explicitly#72
dieterbaier merged 1 commit into
mainfrom
issue_71

Conversation

@dieterbaier

Copy link
Copy Markdown
Member

Closes #71.

find_engine always picked podman when present, with no way to override. A
consuming project's main build broke on it today: podman run died with
crun: unknown version specified on GitHub's ubuntu-24.04 runner, reproduced
on a re-run, while docker on that same runner was demonstrably healthy — the
repository's backend job runs Testcontainers against it.

DOCS_TOOLBOX_ENGINE now short-circuits detection, in both build.sh and
templates/scripts/build.sh.

Why not a better probe

The detection could not have caught this, and it is worth saying why in the code
rather than only here: podman info reports that the engine is configured. It
says nothing about whether the OCI runtime can start a container. The probe was
green about something that did not work.

A faithful probe would start a throwaway container with the same runtime flags
the real invocation uses. That is not in this PR: it costs an image pull before
every run, and two pulls on a host where podman is broken — a regression in the
common case to fix an uncommon one. If this turns out to be widespread rather
than a runner quirk, it is worth revisiting, and #71 records that.

Tests

Two new cases in test/build-sh-template.test.mjs, using stub podman/docker
executables on PATH so nothing is pulled:

  • container mode still prefers podman when nothing is forced
  • DOCS_TOOLBOX_ENGINE wins even though podman is present and its info probe
    succeeds — which is the case that matters, since that is exactly the state a
    broken OCI runtime leaves the host in

The override test was confirmed to fail against main (not ok 6).

./build.sh test and ./build.sh check-adapters both exit 0.

🤖 Generated with Claude Code

Detection always picks podman when it is present, with no way to say
otherwise. That broke a consuming project's main build today: on GitHub's
ubuntu-24.04 runner `podman run` died with "crun: unknown version
specified" while docker on the same runner was demonstrably healthy --
the backend job runs Testcontainers against it.

The detection could not have caught this. `podman info` reports that the
engine is configured; it says nothing about whether the OCI runtime can
start a container, and that is precisely the gap the failure lives in.
The probe was green about something that did not work.

A faithful probe would start a throwaway container with the real runtime
flags. Not done here: it costs an image pull before every run, and two on
a host where podman is broken -- a regression in the common case to fix
an uncommon one. Naming the engine is cheap, explicit, and puts the
choice where a reader of the CI workflow sees it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@dieterbaier dieterbaier left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Es gibt einen blockierenden Randfall im neuen Override:

find_engine übernimmt jeden nichtleeren Wert aus DOCS_TOOLBOX_ENGINE. run_in_container behandelt aber nur podman und docker und besitzt keinen *)-Zweig. Bei beispielsweise

DOCS_TOOLBOX_ENGINE=dockre ./build.sh validate

läuft der case ohne Aktion durch und das Skript endet mit Exit 0. CI wäre damit grün, obwohl weder Validator noch Container gestartet wurden.

Das sollte fail-fast gelöst werden, entweder indem find_engine ausschließlich podman|docker akzeptiert oder indem run_in_container für unbekannte Werte eine klare Fehlermeldung ausgibt und mit Exit 2 abbricht. Dazu sollte ein Negativtest kommen, der für einen unbekannten Engine-Namen einen Non-zero-Exit und keine Container-Inkaufnahme erwartet.

Der eigentliche Fix für #71 ist ansonsten stimmig:

  • Der explizite Override gewinnt korrekt vor der Podman-Erkennung.
  • Root-Skript und Consumer-Template sind synchron angepasst.
  • Die Entscheidung gegen einen zusätzlichen Probe-Container ist nachvollziehbar und vermeidet unnötige Pulls.
  • Der positive Override-Fall ist reproduzierbar mit Stubs getestet.
  • Der GitHub-Workflow Validate ist für den aktuellen Head grün.

Wegen des stillen erfolgreichen No-op würde ich PR #72 in diesem Stand noch nicht mergen. Eine formale Änderungsanforderung lässt GitHub beim eigenen PR nicht zu; daher markiere ich den Punkt hier ausdrücklich als blockierend.

@dieterbaier
dieterbaier merged commit de7c2ad into main Jul 29, 2026
1 check passed
@dieterbaier
dieterbaier deleted the issue_71 branch July 29, 2026 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

build.sh cannot be told which container engine to use

1 participant