This looks useful, but it seems like the default should be to *not* do this.
I don't know about the rest of you, but most of the time I'm *not* watching
Hudson jobs to see the moment they fail, nor am I prepared to attach a
debugger the instant a devtest fails. If I'm going to debug a devtest,
I first prepare my environment for doing so.
Byron Nevins wrote on 04/ 4/11 12:06 PM:
> Our DevTests are all-or-none. One test failing is just exactly as bad as 100
> tests failing. I added a feature that makes it a bit easier to debug problems.
> Read on if interested...
>
> The monitoring devtests ALWAYS run with jpda debugging turned on (suspend = "n",
> of course!!). The moment ANY test fails the screen is cleared and the output
> below is displayed. The code will sit and wait 60 seconds for you to attach
> your debugger to port 9999. It even tells you how to force it to stop waiting
> early so you can start debugging -- by setting a static variable to true.
>
> This will add one minute to every failed test so I suppose this could create
> hudson issues. For now I'm setting a magic environmental variable in the Hudson
> runs that skip this wait.
>
> APS_NO_WAIT=true
>
> Now if we get some weird issue where Hudson fails but your environment succeeds
> -- then simply change hudson.sh and don't set the variable and then you can
> debug at the exact right moment on the Hudson machine!
>
> -- Currently this only applies to monitoring devtests but it can be used for all
> devtests. The main work is adding the right jvmargs to the bazillion different
> ant targets in build.xml
>
> A very useful technique is to attach and then set a breakpoint in the code right
> after the failed test (look in the call stack). Once it hits, I can leave the
> debugger and I now have full access to the server(s) in exactly the state I
> want. I can run plenty of manual tests directly with the server (what does get
> -m return? Which instances are really running? etc., etc.)
>
> =========================================
>
> [java]
> [java]
> [java]
> [java]
> [java]
> [java] ***************************************************************
> [java] ***************************************************************
> [java] ***************************************************************
> [java] ******* TEST ERROR!! Attach a Debugger NOW at port 9999
> [java] ******* To stop the timeout:
> [java] ******* Set the "stopWaiting" variable to true in MonTest
> [java] ******* I'll wait for 60 seconds...
> [java] ***************************************************************
> [java] ***************************************************************
> [java] ***************************************************************
> [java]
> [java]
> [java] 10
> [java] 20
> [java] 30
> [java] 40
> [java] 50
> --
> Oracle <http://www.oracle.com>
> Byron Nevins | Principal MTS
> Phone: +1 6503958992 <tel:+1%206503958992>
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment