Access to runner/container id

[joaomilho]

I have a peculiar use case, where I'm using dockest for the validation of service APIs. In this context, I would like to tap into the container logs and also be able to send signals to the processes (e.g. SIGTERM). I see some alternatives and would like to hear your thoughts.

You already have a dockerEventStream$ in the runner that I could use. Another one would be to get somehow the container id and run docker logs myself. I would probably also need it for sending signals.
https://github.com/erikengervall/dockest/blob/master/packages/dockest/src/run/waitForServices/resolveContainerId.ts#L11-L15

I'm not very sure with the solution here, but some sort of lifecycle callback would be handy, like:

dockest.run(..., {
  onReady: ({ containerId }) => {
    // ...
  }
});

This onReady would get things like containerId and other things that may be useful and, I guess... set some env vars so that the tests can pick up (onReady should be before runJest happens).

LMK your thoughts.

[joaomilho]

I also feel that dockest could be split into 2 libs, one that would simply be a drive for docker-compose (like https://github.com/apocas/dockerode or https://github.com/AgustinCB/docker-api) and then one that couples that with running Jest. WDYT?

[erikengervall]

Hey @joaomilho 👋🏼

I have a peculiar use case, where I'm using dockest for the validation of service APIs. In this context, I would like to tap into the container logs and also be able to send signals to the processes (e.g. SIGTERM). I see some alternatives and would like to hear your thoughts.

You already have a dockerEventStream$ in the runner that I could use. Another one would be to get somehow the container id and run docker logs myself. I would probably also need it for sending signals.
https://github.com/erikengervall/dockest/blob/master/packages/dockest/src/run/waitForServices/resolveContainerId.ts#L11-L15

I'm not very sure with the solution here, but some sort of lifecycle callback would be handy, like:

dockest.run(..., {
  onReady: ({ containerId }) => {
    // ...
  }
});

This onReady would get things like containerId and other things that may be useful and, I guess... set some env vars so that the tests can pick up (onReady should be before runJest happens).

LMK your thoughts.

Adding life cycle events such as this is definitely possible and shouldn't be all too difficult. If you've got time to start drafting a PR I'd be happy to assist. This is where containerIds are resolved and should serve as a good starting point.

I also feel that dockest could be split into 2 libs, one that would simply be a drive for docker-compose (like https://github.com/apocas/dockerode or https://github.com/AgustinCB/docker-api) and then one that couples that with running Jest. WDYT?

Hm, haven't considered this particular split before. It'd have to be worth the investment compared to e.g. adding additional configuration to achieve similar results.