Make sure the server process dies on error #75
Conversation
It didn't actually test anything, because it stubbed the wrong method name.
It might be that the server process got started, even if we weren't able to connect to it. For example, sometimes bootstrapping the environment may take too long.
|
Hold your horses, it might be that the fix introduced another issue. Let me test it a bit more. |
|
This will not work, since Server#stop can only stop a process that has been spawn by the current process. To implement killing a process spawned by a previous guard-jasmine instance, the pid must be written to a file and be read again on startup. |
|
Feel free to close this, since we came up with a workaround. I think the issue still exists, though. My intention was to kill only the processes spawned by the current process. To my understanding, the issue looks like this:
It looks like the child process didn't die gracefully, and I had to 'kill -9' it. The situation might look a bit different if the port was already reserved by some other process in the beginning, but it's also kind of problematic, because it's not properly handled (you could be running tests against a wrong version of code). |
|
Oh, you understand my code better than I do, thanks for the explanation :P I've merged you're changed and also added a new |
It's possible that a server process is spawned and it is alive, even if runner_available? returns false. This change calls Server.stop to make sure that the server won't hang around forever.
This caused an issue with our CI server, where one failed test run left a child process that held the listening socket, and further test runs would fail.
I also fixed a small typo in the 'without the runner available' spec.