Skip to content

test(tmachine): prepare runner environments for the e2e/rust migration #5275

Open

Description

@matthewgrossman

User Story

I maintain OpenShell's end-to-end coverage and am moving the e2e/rust suite onto testkit and the tmachine runner. Before those tests can move, every tmachine runner environment needs the same basics the old lanes had, so ported tests behave the same on Docker, Podman, k3s and k3s-ha.

Description

Two gaps block the port:

  1. host.openshell.internal on k3s. Docker and Podman provide this alias natively. The tmachine k3s and k3s-ha installs don't set the Helm value server.hostGatewayIP, so sandboxes there can't reach a server the test starts on the VM. The e2e-host-gateway tests and the Kubernetes shared-supervisor tests depend on it.
  2. Python workload image in every environment. Many e2e/rust tests run python3 in sandboxes. tmachine already builds openshell/e2e-python:dev but only loads it for the Podman e2e testsuite. Load it on every installer (Docker, Podman, k3s containerd) and give testkit an env var and helper for it next to OPENSHELL_TEST_BASE_IMAGE. The base image default doesn't change.
    A small features test proves both: a sandbox running the Python image reaches a server the test starts on the host through host.openshell.internal, on every runner row including k3s and k3s-ha.

Context

Definition of Done

  • k3s and k3s-ha tmachine installs set server.hostGatewayIP so host.openshell.internal resolves to the VM from sandboxes.
  • openshell/e2e-python:dev is available to sandboxes in every tmachine installer, and testkit exposes it through an env var and helper.
  • A features test that reaches a host server through host.openshell.internal passes on every runner row.

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions