Skip to content

test(podman): run existing Podman behavioral e2e coverage in CI #3712

Description

@johntmyers

User Story

As an OpenShell maintainer, I want the existing Podman behavioral end-to-end tests to run in required CI and release qualification, so that Podman-specific networking, lifecycle, policy, identity, resource, and provider regressions cannot merge while applicable tests remain unscheduled.

Problem Statement

OpenShell currently has a required bundled-Podman branch job, but it runs a hard-coded PODMAN_CI_TESTS allowlist rather than the full set of targets eligible under the e2e-podman feature.

There are currently 39 eligible Rust test targets. The curated CI set selects 20 and omits 19. Two omissions are intentionally ignored performance benchmarks, leaving 17 executable targets outside Podman behavioral CI.

Twelve of those 17 are shared, driver-independent test targets that run from the same source files in Docker and Kubernetes CI but are explicitly omitted from Podman CI:

  • port_forward
  • provider_auto_create
  • proxy_egress_pipeline
  • sandbox_labels
  • sandbox_lifecycle
  • sandbox_templates
  • settings_management
  • sync
  • transparent_tcp
  • upload_create
  • websocket_conformance
  • workspace_lifecycle

Five are Podman-specific targets whose behavior cannot be covered by another driver:

  • podman_oci_identity
  • podman_preflight
  • podman_resource_limits
  • podman_userns
  • provider_refresh_handles

podman_preflight may need a separate lightweight invocation because it expects the standalone openshell-driver-podman binary. The older podman_userns Rust target should either run or be removed as superseded by the newer rootful/rootless tmachine user-namespace suite.

The bundled Podman behavioral job is also present only in the branch workflow. Release Dev and Release Tag do not run the bundled Podman behavioral suite.

This is a follow-up to #3663. PR #3690 added the resource-limit and daemon-failure targets and broadened rootful user-namespace testing, but the new Rust targets were not added to PODMAN_CI_TESTS. PR #3606 restored a bundled Podman branch lane after the host.openshell.internal regression, but intentionally limited it to targets known to pass at that time.

Impact / Why This Matters

This scheduling gap has already allowed a Podman host-networking regression to merge even though relevant e2e coverage existed. It creates the same exposure for transparent networking, proxy enforcement, port forwarding, lifecycle cleanup, resource enforcement, OCI identity, workspace operations, and credential refresh.

The current workaround is for contributors to know that mise run e2e:podman is broader than required CI and run it manually on a compatible Linux Podman host. That is insufficient because:

  • contributors reasonably treat required CI as the supported regression suite;
  • the omission is not visible from individual test files or Cargo feature gates;
  • many developers do not have a compatible rootless Podman/AppArmor/pasta environment;
  • Release Dev and Release Tag can qualify artifacts without bundled Podman behavioral coverage; and
  • newly added Podman-eligible targets can silently remain outside CI.

Acceptance Criteria

  • All 12 shared executable targets listed above run against the bundled Podman driver in required branch CI and pass reliably.
  • podman_oci_identity, podman_resource_limits, and provider_refresh_handles run against a real Podman-backed OpenShell gateway in CI.
  • podman_preflight runs in CI with the standalone Podman driver artifact and verifies the bounded, actionable daemon-unavailable failure path.
  • podman_userns is either enabled or removed with its assertions demonstrably covered by the rootful/rootless driver-podman tmachine suite.
  • The two intentionally ignored performance targets remain documented as manual benchmarks rather than appearing as unexplained CI omissions.
  • Release Dev and Release Tag include bundled Podman behavioral qualification, or a documented release-gating replacement provides equivalent coverage.
  • CI contains an inventory/reachability check that fails when a new non-ignored e2e-podman target is not selected by a workflow, unless it appears in a checked-in exclusion list with a rationale and tracking issue.
  • Job names and summaries report the selected test set or target count so a narrow Podman job cannot be mistaken for the complete suite.
  • Rootless and rootful scope is explicit. Any behavioral targets not run in both modes have a documented technical reason and tracking issue.

Reproduction Steps

  1. Compare the [[test]] declarations and auto-discovered files under e2e/rust/tests/ that are eligible with the e2e-podman feature against PODMAN_CI_TESTS in e2e/rust/e2e-podman.sh.
  2. Observe that 39 targets are eligible while only 20 are selected by OPENSHELL_E2E_PODMAN_TEST_SET=ci.
  3. Observe that 17 non-benchmark targets are omitted.
  4. Inspect .github/workflows/branch-e2e.yml and observe that required branch CI invokes mise run e2e:podman:ci, not the full mise run e2e:podman suite.
  5. Inspect .github/workflows/release-dev.yml and .github/workflows/release-tag.yml and observe that neither has a bundled Podman behavioral job.

Environment

  • OpenShell: main at 924486805
  • Required Podman lane: Ubuntu 26.04, Podman 5.7.0, rootless/pasta
  • Relevant files: e2e/rust/e2e-podman.sh, e2e/rust/Cargo.toml, .github/workflows/branch-e2e.yml, .github/workflows/e2e-podman-test.yml

Related Work

Activity

  1. politerealism commented on Sep 27, 2026

    @politerealism
    Contributor

    Looking at this one

  2. politerealism commented on Sep 27, 2026

    @politerealism
    Contributor

    Plan and order of operations

    This issue overlaps significantly with open PR #3637 ("test(e2e): run podman suite with tmachine", author elezar), which independently adds a tmachine-based e2e-podman nextest archive (43 tests passing) covering most of the 39 eligible e2e-podman targets, removes podman_userns.rs as superseded by the driver-podman tmachine suite (resolving that acceptance criterion directly), and depends on PR #3597 (migrates sync.rs coverage into conformance scenarios). Both #3637 and #3597 are currently green in CI but show mergeable: CONFLICTING and need a rebase before they can land.

    Order of operations for this work:

    1. Treat test(e2e): run podman suite with tmachine #3637 + test(conformance): migrate file transfer coverage #3597 as prerequisites. This plan does not duplicate their work and does not touch the files they modify (tests/ansible/playbooks/drivers/podman/e2e.yaml, tests/artifacts.nix) until they're on main.
    2. Track A (starting now, independent of test(e2e): run podman suite with tmachine #3637):
      • Wire podman_preflight into CI via the existing podman-external-driver-e2e job's already-exported driver binary artifact (it never runs anywhere today because that job's mise task disables the cargo-test step for other reasons).
      • Add an automated inventory/reachability check (new tasks/scripts/check-podman-e2e-coverage.sh, modeled on check-cargo-lockfiles.sh) that fails CI if a new e2e-podman-eligible test target isn't accounted for in either PODMAN_CI_TESTS or a documented exclusion — this directly satisfies the acceptance criterion preventing silent future omissions like this one.
      • Document the current test-selection contract in CI.md.
    3. Track B (after test(e2e): run podman suite with tmachine #3637 + test(conformance): migrate file transfer coverage #3597 merge):
      • Extend the coverage check to also read test(e2e): run podman suite with tmachine #3637's podmanE2eFollowUpBinaries exclusion list; file tracked follow-up issues for the exclusions that need distinct scope work (sandbox_lifecycle conformance migration, podman_oci_identity SPIFFE fixture plumbing, provider_refresh_handles's own purpose-built suite), and link transparent_tcp's exclusion to the existing test(e2e): restore musl DNS probe coverage for guest prebuilt artifacts #3009 rather than duplicating it.
      • Investigate the remaining plausible quick-fix targets (provider_auto_create, proxy_egress_pipeline, websocket_conformance, workspace_lifecycle) against a live tmachine environment.
      • Add a rootful leg to the new tmachine e2e-podman testsuite (its current playbook hardcodes rootless-only values instead of using the tmachine_container_runtime role the way driver-podman's playbooks already do).
      • Wire driver-podman/e2e-podman into Release Dev and Release Tag qualification, mirroring the existing provider-refresh job pattern.
      • Add visible selected-vs-eligible test-count reporting so a narrow run can't be mistaken for full coverage.

    PRs for Track A will follow this comment. Track B PRs will follow once #3637/#3597 land.

  3. politerealism commented on Sep 29, 2026

    @politerealism
    Contributor

    Status update given everything that's landed since the plan above:

    @elezar — given #3460 (Nix/tmachine target-state doc) and the string of test(conformance)/test(tmachine) PRs you've got in flight (#3766, #3768, #3792, #3795, #3839, etc.), it looks like most of the remaining shared-target and driver-specific coverage gaps here (the 6 of 12 shared targets still excluded, podman_oci_identity, provider_refresh_handles) will fall out of that migration rather than needing separate Podman-specific CI wiring. To avoid duplicating effort, I'm deliberately not touching that migration.

    What I'll pick up next instead, since it's orthogonal to the conformance/driver-specific split:

    • Release Dev and Release Tag bundled Podman behavioral qualification (currently absent from both).
    • Selected-vs-eligible test-count reporting in job names/summaries, so a narrow run can't be mistaken for full coverage.
    • Documenting the rootless-only scope of the current e2e-podman tmachine archive (only fedora-podman-rootless runs it; podman_resource_limits specifically would benefit from a rootful leg since it reads real cgroup v2 state and rootless cgroup delegation is the harder/riskier case).

    Flag anything above that's already in flight or planned elsewhere so we don't collide again.

  4. elezar commented on Sep 30, 2026

    @elezar
    Member

    Thanks @politerealism. I am busy constructing a plan to migrate the e2e/rust tests that are covered by the e2e-podman feature so that we can tackle that in parallel.

  5. politerealism commented on Oct 6, 2026

    @politerealism
    Contributor

    Update 2026-10-06: Following up on the 2026-09-29 note above where I deferred the e2e/rust→conformance migration to @elezar to avoid duplicating his in-flight work.

    Coordinated directly with Evan today on the 11 general-conformance candidates I'd flagged in a research pass on #3460. He confirmed his own plan (verify under Podman, relax gates on provider_refresh_handles.rs/websocket_conformance.rs, sandbox_labels.rs needs nothing) and suggested migrating applicable ones straight into tests/suites/conformance/ rather than gate-relaxing in place — and invited a partial migration on my end rather than a hard handoff.

    Migrated so far (branch not yet opened as a PR, pending final review on my end):

    • workspace_lifecycle.rs → workspace-lifecycle/workspace-terminating scenarios
    • upload_create.rs → file-transfer/create-upload scenario (grouped with the existing file-transfer family)
    • provider_auto_create.rs → provider-auto-create scenario
    • sandbox_templates.rs → 4 scenarios (lifecycle, get-after-delete, duplicate-name, missing-template)
    • settings_management.rs → settings-management scenario

    All verified against an ephemeral Podman gateway. Will reference #3954 (not this issue) when the PR opens, since that's the umbrella tracking issue for the RFC-0016 testing-strategy work this falls under.

    Two things surfaced along the way worth noting here:

    • port_forward.rs doesn't fit the conformance harness's CLI request/response model (needs a long-lived background SSH-tunnel process + raw socket I/O) — holding that one for Evan's input on whether that pattern belongs on OpenShellRunner or as a scenario-local bypass.
    • Found two of Evan's already-landed file_transfer.rs conformance scenarios (round-trip, git-filtering) currently failing against main — pre-existing, unrelated to this migration, flagged to him separately.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions