Summary

get_docker_cmd() in .evergreen/orchestration/drivers_orchestration.py prefers podman unconditionally. On some GitHub-hosted ubuntu-24.04 runners, podman pulls the image and then crun refuses to start it:

Error: OCI runtime error: crun: unknown version specified
##[error]Process completed with exit code 126.

This is intermittent — re-running the same job passes — so it appears to depend on which runner the job lands on, consistent with GitHub rolling out images gradually across a heterogeneous fleet.

Docker is preinstalled and working on those runners, and the file already checks GITHUB_ACTION to decide about the ECR pull-through cache, so the same signal can pick the CLI:

if "GITHUB_ACTION" in os.environ:
    docker = shutil.which("docker") or shutil.which("podman")
else:
    docker = shutil.which("podman") or shutil.which("docker")

Evergreen keeps podman, which it needs for the sudo prefix, --health-cmd, and podman healthcheck run.

Motivation

Who is the affected end user?

Driver teams using this repo's setup-mongodb action with local-atlas, plus this repo's own Tests workflow.

How does this affect the end user?

Annoyed rather than blocked: the job fails, and a re-run generally clears it.

How likely is it that this problem or use case will occur?

Intermittent, frequency unmeasured. Only affects local-atlas on GitHub Actions; Evergreen is unaffected.

If the problem does occur, what are the consequences and how severe are they?

A spurious red build and a wasted re-run. Minor in isolation, but it erodes trust in the signal since the failure looks like a real container startup error. No product or data impact.

Is this issue urgent?

No. No deadline, and it may disappear once GitHub's fleet converges on a fixed image. Worth doing anyway to remove the flaky dependency on podman where docker is available.

Is this ticket required by a downstream team?

Not required, but it benefits driver repos whose GitHub Actions workflows use local-atlas.

Is this ticket only for tests?

No product impact, but it is runtime code in the composite action that downstream repos execute — not just a test improvement.

Acceptance Criteria

• get_docker_cmd() prefers docker when GITHUB_ACTION is set, podman otherwise.
• The local-atlas job of Tests passes on ubuntu-latest.
• Evergreen behaviour unchanged: podman with sudo, --health-cmd, and podman healthcheck run.
• Confirm the health wait loop works under docker. --health-cmd is passed only for podman, so the mongodb-atlas-local image's own HEALTHCHECK must satisfy docker inspect -f '{{.State.Health.Status'}} or that loop times out after 60s. Unverified.

Notes

Example failing run: https://github.com/mongodb-labs/drivers-evergreen-tools/actions/runs/30555555490