Key: |
QB-938
|
Type: |
New Feature
|
Status: |
Resolved
|
Resolution: |
Fixed
|
Priority: |
Major
|
Assignee: |
Unassigned
|
Reporter: |
Don Ross
|
Votes: |
5
|
Watchers: |
3
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 07/Jun/11 05:24 PM
Updated: 21/Dec/13 02:42 PM
|
|
Component/s: |
None
|
Affects Version/s: |
None
|
Fix Version/s: |
5.1.5
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
Basically, we have a situation where a build step may lock up or loop (no fault of QuickBuild's, just careless programmers), and we need to detect that this is happening and fail out on the build.
I can set a timeout on the entire configuration, which prevents the build from running forever,but that doesn't enable me to take corrective action or collect logs if the build times out.
Plus, if my step is only supposed to run for ten minutes, but the entire build takes an hour, then I have to wait for an hour (or more, to be safe) to pass before detecting the problem.
|
Description
|
Basically, we have a situation where a build step may lock up or loop (no fault of QuickBuild's, just careless programmers), and we need to detect that this is happening and fail out on the build.
I can set a timeout on the entire configuration, which prevents the build from running forever,but that doesn't enable me to take corrective action or collect logs if the build times out.
Plus, if my step is only supposed to run for ten minutes, but the entire build takes an hour, then I have to wait for an hour (or more, to be safe) to pass before detecting the problem. |
Show » |
|
Create a parallel step, put your original step into it and the second step is the timeout-step.
Timeout-Step (type: Shell/Batch Command) contains (windows only code):
PRESTEP:
groovy: //wait startuptime
Thread.sleep( Long.parseLong( vars.getValue("maxstartuptime_ms") ) ) //wait a given time
//in my example i stored this time in a variable and it's 3 minutes.
MAIN STEP:
cmd /c start taskkill -IM ${vars.getValue("exe_name")}.exe
This workaround has the ugly side-effect that i ALLWAYS takes the maximum timeout time, because it always waits the full time. The command "start" before taskkill is needed so that it doesn't fail if it can't find the exe (but taskkilling another programm results in "return 1" to cmd, what makes the step fail.
Due to this bad side effect i'd really like to see a fix for this, because it would speed up all builds that use this step by ~2 minutes.