Module docker_proxy 

Containers a suite starts, through any Docker client.

The suite’s DOCKER_HOST points at a socket of Supercov’s that relays the Docker Engine API to the daemon the user’s own client would reach. Every request passes through unchanged but one: creating a container. A container whose image holds the copy’s instrumented code is given the run’s settings and Supercov’s directory, mounted at the path it has outside, so the code in it writes its evidence where the run reads it. docker compose, docker run, testcontainers and the SDKs all create containers this way, so one place serves them all.

Which images hold the copy’s code:

• a compose service whose build context is in the copy, which the relay builds from the copy before the container is created: an image left over from an earlier run is never used;
• any image created while the run was going: the suite built it, from the copy it runs in;
• an image an earlier run recorded as built from source identical to this run’s: a build that found everything cached returns it, unchanged.

An image built from an earlier copy is left alone, and the run says so: its probes were placed in other source. At the end the run stops the containers it measured, and the rest of their compose projects, so each writes its last evidence; it never removes them.

Structs

DockerProxy

A running relay.

ProxySettings

What the relay gives the containers it measures.

Constants

CONTAINER_VARIABLE

Set in each measured container: its runtime runs in an image of the copy.

Functions

notes

The notes the relay recorded about containers it left alone.

socket_path

Where the relay listens: in the run’s own directory when the path fits a socket address (104 bytes on macOS, 108 on Linux), or else in a private directory of its own under /tmp.

upstream_socket

The daemon a client would reach without Supercov, as a socket path. None when it is not a local socket (a TCP or SSH daemon), which the relay does not stand in for.