Skip to content

Add static container feature

Jon Foss Mikalsen requested to merge static-compositions into master

Static containers enable two new workflows through their associated ManagementPolicy:

  • External: External containers are managed outside dockertest and we will map them into dockertest using their user specified container name. Teardown is never performed for external containers.
  • Dockertest managed: Static containers managed by dockertest will behave as normal containers, but will ignore all prune strategies and will be cleaned up after all tests that references them has finished. Users can reference the same static container across tests by using the same container name for their composition and setting the container as static. For synchronization of container creation/startup a single test will be responsible for executing the containers associated WaitFor implementation and creating the container.

User impact

The only change to the existing api is requiring all WaitFor implementations to be Sync. This is required to keep a copy of it in our internal static map.

Limitations

  • We are holding a lock while creating/starting static containers, blocking all other tests depending on the same container until we complete creation/waitfor. If we panic during container creation or startup we have a deadlock.
  • We rely on unique container names.
  • Frequent use of cloning in the implementation (I couldn't find a way around this).

Future possible additions

  • Add feature to exclude static containers from all cleanup and reuse them if they are already running.

Commit history is currently not written, awaiting review of design/implementation to write tests/commit history.

Depends on !56 (merged)

Edited by Jon Foss Mikalsen

Merge request reports