Automatically replace stale reusable containers

[Jc2k]

Building on the work done by @alexanderpetrenz I think we should add some tooling to help make sure you don't develop against stale reusable containers. (This only applies to reusable containers, by default they are always recreated anyway).

User Stories

• Your co-worker has bumped a tag in an image() fixture, for example to use postgres 14 and its new JSON syntax. You git pull and your tests start failing. Sometimes this might not be obvious and the breakage might be some time after the root cause.
• You make a change to some code that triggers a build() fixture. Right now the build() will still run. But the old container will be used.

Proposal

Track staleness using labels. In the simplest case just do a json.dumps() of kwargs before calling the underlying docker API. E.g.

    set_reusable_labels(kwargs, request)

    kwargs.setdefault('labels', {})['pytest-docker-tools.signature'] = json.dumps(kwargs)

    raw_container = docker_client.containers.run(**kwargs)

This might be too large to store on a label so it would be better to sha hash the JSON string (using sort_keys on json.dumps to make extra sure the hash is stable).

Now in reusable mode, after finding a matching container check if its stale. If it is stale, delete it and fall through to the no matching container case.

Edge cases

If this is applied to networks and volumes and we find that one is stale we might try to delete it when it is still used by a container. I believe in this case the right thing to do is enumerate containers generated by pytest-docker-tools and delete the ones that use this network or volume. Because pytest will be running the fixtures in dependency order the deleted containers should be recreated against the correct and updated network/volume in the next step.

Containers that are referenced by other containers are safe to delete. If container b references container a's ip address and container a is recreated, container b will be considered stale and recreated as well.

Alternatives

• Emit a warning instead, telling the user to resolve the issue manually

[Jc2k]

Proof of concept:

#35

This should work for both use cases above, though i've only tested it via pytester so far.

[Jc2k]

Landed in 25ad943.