Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow bypassing handler spawning logic #755

martijnarts opened this issue Mar 20, 2017 · 1 comment

Allow bypassing handler spawning logic #755

martijnarts opened this issue Mar 20, 2017 · 1 comment


Copy link

Hey, it'd be super sweet if there was a native solution for #748. Maybe null could be an argument to language? The spawnHandler and terminateHandler calls could just be bypassed in this case, and that should solve the issue entirely.

Copy link

honzajavorek commented Oct 22, 2019

We did some work around how Dredd is friendly to the Docker setup, but this hasn't been resolved yet. It needs internal refactoring of how the hooks are done in Dredd. The discussion in #748 completely describes the original problem this is trying to solve.

This is also related to #1101 - when re-thinking the --language option and its friends, we should think about this use case, when we want Dredd to just try to connect to a hook handler on a certain port, without starting up any processes itself.

Current behavior:

When using Dredd with non-JS hooks, Dredd needs a hooks handler process. By default, Dredd spawns it as a subprocess and connects to it on a default port over TCP, then Dredd does its job and then kills the hooks handler process before the end of the testing.

The problem:

When used with Docker, people want to run the hooks handler process in a separate container. Dredd supports an option for specifying a non-default port, that's OK, but it requires a --language option and insists on trying to spawn its own hooks handler process. Users with Docker would like to opt-out from the spawning and handle running the hooks handler process by their Docker setup. That's not currently possible.

The workaround:

It's possible to call Dredd with --language set to a dummy shell script, which does nothing forever, and with a port pointing to the actual Docker container with the hooks handler. Dredd spawns the dummy script and thinks it's handling the hooks handler process (although it is not), but connects to the given port and the TCP connection is done with the correct Docker process containing the real hooks handler.

The solution:

This issue can be closed if Dredd provides a way to opt-out from spawning the hooks handler process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants