Feature request: Explicitly defined container dependancies
Ciaran-Whyte opened this issue · 6 comments
Can we add explicitly defined container dependancies to pytest-docker-tools?
i.e depends_on=[ list of containers to start up]
This allows you to list the dependancies between containers without relying solely on implicit declarations.
Which is useful for containers which have shared volumes but no TCP traffic between them.
At the moment to work around this, I've to have ENV's defined to container names to bring up dependancies implicitly
Hi - to make sure i've understood your requirements. You have a volume A and containers B and C. B and C implicitly depend on A. But your code in container C fails unless container B has finished starting already? And you are using docker-compose and depends_on in your prod config or similar already?
Yes, pretty much. We have files moving through a shared volume
[Container B]
=> FILES => (Volume A) => [Container C]
[Container D]
We currently use the depends_on in our docker-compose config to bring up an environment like the one outlined above.
It would be great to have the something like depends_on property in pytest-docker-tools
Ok, cool. I'm fine in principle with adding something like that. It would be a big help if you could put a PR together and test it as i'm a bit busy on my end. I can give you a few clues but its been a while since i worked on it so i might have forgotten something.
We abuse pytests fixture dependency mechanism so what we need to do is make our fixture stub reference these extra containers.
The function that finds the implicit dependencies is here and the stub generator is here. It is quite a horrid thing to look at - apologies.
You should be able to make find_fixtures_in_params
include depends_on
in the set it returns. But you will also need to make sure to update resolve_fixtures_in_params
to do something like:
value.pop('depends_on', None)
renderer = Renderer(request)
return renderer.visit(value)
Otherwise it will pass depends_on
through to the docker API which would be bad.
And that might be enough to make it work...
Sounds good, thanks for pointing me at the right code. It should make things easier
Hey @CiaranWhyteGit - wondering if you got anywhere with this?
I'm going to close this as it's stalled, but i'd be open to merging a PR for this still.