It is enough to add the return value to waitForOrKill():
- true: process has completed
- false: process has been killed.
The functionality is in fact very useful in cases when it is required to log/tell the user what exactly happen. Did we killed the subprocess, or it has failed because of its own issues?
Currently Groovy script has no way to tell it, and so it always looks like the subprocess just failed, potentially causing the user wasted time debugging the subprocess script.
False positive is not an issue, IMHO:
First, the probability of it is small.
Second, we still have the exit code. If exit code is 0, our kill() was too late. It can be checked right inside the waitForOrKill() method() so the return value is always correct.
Third, a process killed right before it exited is still process killed, with the undefined state left after it. Operator will have to review what work was completed/not completed anyway.