didericis-claude
d4d45f835e
Review feedback: the hand-rolled `/dev/kvm` + docker-daemon capability probes duplicated logic the CLI already owns. Delegate instead. - tests/_backend.py skip guards now gate on `bot_bottle.backend.has_backend` (each backend's `is_available()` classmethod — the same probe behind `./cli.py backend status`), dropping the bespoke `Capability` probes. - Remove tests/backend_preflight.py; the docker integration job runs `./cli.py backend status --backend=docker` as its preflight (clear per-check summary, non-zero exit when unready), matching the firecracker job. The firecracker preflight reverts to its original binary/KVM checks (backend status doesn't cover those). - Unit test + docs updated to match. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.0 KiB
CI
The test workflow lives at .gitea/workflows/test.yml.
It runs the unit suite plus one integration job per backend
(integration-docker, integration-firecracker) on:
- every push to a branch with an open pull request, and
- every push to
main.
Each integration job selects its backend via BOT_BOTTLE_BACKEND and
runs a preflight (./cli.py backend status --backend=<name>) that
prints a clear per-check readiness summary and fails the job when the
backend is missing — so absent infrastructure is visible at the job level
rather than hidden among per-test unittest.skip lines. The skip guards in
tests/_backend.py gate on the same readiness
check (bot_bottle.backend.has_backend): backend-agnostic tests use
skip_unless_selected_backend_available() and run through whichever
backend is selected (checking, e.g., Linux + /dev/kvm for Firecracker
rather than unrelated Docker availability); Docker-implementation tests use
skip_unless_backend("docker") and no-op under a non-Docker run.
A small subset of integration tests skip when running specifically
under Gitea Actions (GITEA_ACTIONS=true), because act_runner runs
the job inside a container with the host's /var/run/docker.sock
mounted in. That topology breaks two assumptions those tests make:
- networks created via the host daemon aren't always visible to a
same-process
docker network lscall from inside the job container, and - ports published by sibling containers land on the host's loopback,
not on the job container's
127.0.0.1— so HTTP probes againsthttp://127.0.0.1:<host_port>from inside the job time out.
The affected tests (test_orphan_cleanup.test_create_and_remove,
test_gateway_image.TestGatewayImage) still run
locally where the test process and Docker daemon share a host.
Making them work in CI is a follow-up: either re-write them to
discover container IPs via docker inspect, or reconfigure the
runner with host networking.