Request: allow use of already previous test session Docker containers
devuo opened this issue ยท 7 comments
Context:
Starting Docker containers can take from a few seconds to some minutes depending on the Docker image being used.
The current implementation forcefully kills containers if there is already one running with the same container name. This impedes the ability of setting up a faster test workflow for developers to do so: the re-use of the same container in different test runs.
Proposal:
Allow developers to pass an option like .WithContainerNameReuse("some-container-name")
(or other some other option name) that would make Gnomock re-use the container with the given name, instead of killing it and starting a new.
I'm more than happy to implement this myself and open a PR, but first would need to know if this functionality is something that you'd find OK to be added to gnomock @orlangure
Hi @devuo, I like the idea!
I can already see two scenarios that we might need to support:
WithContainerReuse
orWithExistingContainer
that simply translates container information intognomock.Container
object that can be used in tests (with all thec.DefaultAddress
goodies). The setup in this case is basically zero.WithContainerReset
or something like this for cases where the container already exists, but needs to be cleaned up before using in a new test. For example, a database needs to be dropped and created again between tests inside the same container. In this case, we should think through the desired API. What would be the clean up code? Maybe per preset? LikeWithContainerReset(postgres.Reset())
, and each preset will implementReset
function that drops everything somehow. Can be tricky.
We can start with the first option of course and see how it goes, but I would like to eventually support both. What do you think?
That's great to hear
If you can, please go ahead.
Thank you.
The first step is now merged, and I'll create a new release soon, thanks to @devuo
I really liked the second, much more complex feature mentioned here, I think it would be great to start thinking about it as well. I'll give it a thought in the background, and I hope somebody can offer some help with defining the feature a bit better so we can proceed to actually implementing per-preset cleanups.
I submitted a first draft of how the reset feature (continuation of reuse) can look like.
Here is the postgres reset implementation as an example: #699
The naive way is to provide a single cleanup function, that can do any work
type ResetFunc func(*Container) error
It works good for postgres since there should be an easy way to drop almost everything and restore with init
function provided by the preset. A single function for the entire postgres
package works.
When I tried to implement the same thing for localstack
package to clean-up s3 buckets, I understood that this way might be wrong, and maybe the function should sit on the Preset
instance instead, and Start
will accept a Resetter
instance instead of a single function.
type Resetter interface {
Reset(*Container) error
}
The advantage is that the Reset
function eventually must have access to the preset configuration, such as "which AWS services were requested in this localstack container?", and this will allow to delete buckets only if s3 exists (otherwise there might be an error).
The downside is that a single interface will make the Reset
function unconfigurable beyond the underlying preset configuration. I can think of a few options that I might want to send to Reset
in the future, such as WithKeepSchemas
in postgres or WithKeepIAM
in localstack).
@devuo do you have any thoughts on the issue? I think your input is very valuable, because you built the ability to reuse containers, and this feels like the next step in the same direction.
Of course if anybody else sees the issue and has something to say about it, please go ahead
Hey @orlangure that's great, will give feedback in the next day or two