Cancelling build does not cancel tests

[taliesins]

We have setup Specflow to run Webdriver using Xunit. We have noticed that if you stop a build in TeamCity it does not close xunit.console.exe.

This leaves test running in the background. I was expecting the process to be terminated, if the job is stopped in TeamCity.

[carlpett]

Thanks for reporting! I will have a look - my assumption was that this was handled by the base class from the TeamCity API I extended, but I may have misread the documentation.

[carlpett]

@taliesins I've made a fix for this now, available in version 1.1.3. Could you give it a try?

[taliesins]

I clicked stop in TeamCity. The xUnit runner was killed, but child processes stayed alive. I was hoping it would also kill all child processes.

So in the specflow scenario I landed up with 1 chromedriver.exe and 4 chrome.exe instances. I have hooked into the app domain unload event as well as creating a critical finalizer in the hope I can kill off the processes, but they stayed alive.

[carlpett]

@taliesins Hm, that turns out to be a bit tricky, it seems... Java does not support signalling or killing child processes, as far as I can see, due to it being hard to do in a cross platform manner. There are a few posts with hacks involving WMI around the net, but nothing that seems particularly robust (in your case we probably have multiple levels of subprocesses, for instance).
I'm a bit surprised that xUnit would not handle this more gracefully, I'll do some reading and see if there's kinder ways than Process.destroy() to stop.

[taliesins]

Can you send ctrl+c twice sleep a bit then call process.destroy() as this would allow xunit to cancel itself gracefully and allow me to hook into subdomain unload.

[taliesins]

https://github.com/xunit/xunit/blob/master/src/xunit.console/Program.cs

Send ctrl + c, sleep, send ctrl + c, sleep, process.destroy()

[carlpett]

Yes, part of the problem is that ctrl+c isn't really a character that can be sent to an input stream, it is a keystroke which is interpreted by the shell when you are running it interactively.

From what I've gathered, I'll need to get into JNA and send a Windows message to the application. I'm looking into exactly what I need to do for that (I'm don't do any Java development outside of this plugin, so it's a bit slow, I'm afraid)

[taliesins]

I think I may have an easy solution for you.

http://www.latenighthacking.com/projects/2003/sendSignal/
https://github.com/walware/statet/tree/master/de.walware.statet.r.console.core/win32

So pass the process id to sendsignal.exe and it will send ctrl+c to the process.

[carlpett]

@taliesins First, thanks for taking an active part in resolving this :)

I looked into sendsignal a bit, and I think there might be a few issues with that approach sadly. The Java Process class' many shortcomings include not exposing the PID. That could of course be solved by enumerating all processes and looking for the test runner. However, quite a few deployments of TeamCity (including some of those I work with, despite my protests) run several agents on the same machines. When this happens, it will not be possible to know which process should be targeted.

As a temporary workaround, in case you do run multiple agents as described above, would it work for you to add an extra build step at the end of your build with the "Run always, even if build stop command was issued" execution policy which calls sendsignal (or something similar)?