Bug: Incompatible with Development Containers

[finite8]

Describe the bug
When gnomock is used to launch a container when run inside of a devcontainer it fails to start. This is because of how it initializes and checks the state of the launched container by using the resulting ip address of the container. When being executed from within a devcontainer, the container is a peer to the other containers being launched, not a child like it is when run directly on the host.

To Reproduce

• Take an existing test that uses gnomock and run it inside of a development container
• Test will fail as the launch will not be able to reach the container by IP address

Expected behavior

• The container should launch

Additional context
My current workaround is in this fork here: master...finite8:gnomock:master
The reason why the init phase was not acceptable is that it was unable to change the actual host details prior to the other checks occurring. This means that no matter what "host" it is set to, the resulting container cannot be adressed. This change allows it to be worked around by invoking additional setup options when being run inside of a container. For example:

gnomock.WithPostCreate(func(ctx context.Context, c *gnomock.Container) error {
				cmd := exec.Command("docker", "network", "connect", "devnet", "kafka")
				cmd.Env = append(cmd.Env, "PATH="+os.Getenv("PATH"))
				fmt.Println(cmd.Env)
				c.Host = "kafka"
				return cmd.Run()
			})

Because this modifies the original gnomock.Container instance, with the host now specified and the network now created, it allows the dev container to correctly communicate with the "kafka" container by name and it operates as expected. Without it, it fails during initialization.

[orlangure]

Hi @finite8, thank you for reporting this.

Do you think there is a better way to solve the reported problem than your suggested workaround?

If it works, it looks good to me. It won't affect most of the use cases, and only some weird edge cases will require using this new callback.

[finite8]

I think my workaround is a bit hacky. To make it work it tries to connect the container it just created to a network common to the dev container, and because it is modifying the underlying "container" instance before it is used by the packages internal health-check logic it allows it to look it up by name.

There may be an easier / more agnostic way to get two containers to discover eachother without relying on sharing a network, but the main thing my change did was allow for this hack to be employed.