Recognize when a container is already running

[leventov]

Is your feature request related to a problem? Please describe.
If a container is already running, currently, Dockest timeouts in 30 seconds because it awaits for Docker start event:

dockest/packages/dockest/src/run/waitForServices/resolveContainerId.ts

Lines 9 to 20 in 7da1dda

	export const resolveContainerId = async ({ runner, runner: { logger, dockerEventStream$ } }: { runner: Runner }) =>
	race(
	dockerEventStream$.pipe(
	first(event => event.action === 'start'),
	tap(({ id: containerId }) => {
	logger.info(`${LOG_PREFIX} Success (${containerId})`, { success: true })
	runner.containerId = containerId
	}),
	),
	interval(1000).pipe(
	tap(i => {
	runner.logger.info(`Still waiting for start event... Timeout in ${DEFAULT_TIMEOUT - i}s`)

If Dockest allowed reusing existing containers, a developer could start a container once and make debugging loop shorter, because they don't need to wait for a container startup every time.

noRecreate option in composeOpts doesn't seem to work. It has nothing to do with the await of the start event in the code above.

[n1ru4l]

We can check whether a container is already running by using docker-compose ps -q <service-name>. However, we then could no longer rely on the container start events, as the event log is limited to the last 1000 occurring events. The approach would be a bit slower as we then need to poll again :/

[erikengervall]

I understand your use-case and I'd love for the local development experience to be smoother.

The focus of the library so far has been to create a means of running reliable integration tests in e.g. pipelines, rather than fast iterative local development.

I feel as if these concepts conflict with one another, which makes it hard to accommodate both without compromising reliability (which is still feel should be core).

I always welcome suggestions and/or PRs to amend this.

This could possible be an option in the future CLI (here's a first draft) which would alter behaviours, e.g. run docker-compose ps -q <service-name> rather than relying on docker events 🤷‍♂