Hi Will, The timeout is implemented in the worker side. There is no signal sent to the master telling that the command timedout.
To my opinion, this is a shame, and I would expect that a timeout of a step should put the step in EXCEPTION (which is buildbot's equivalent to Jenkins unstable results) meaning that the build result cannot be decided. Fixing it is not too easy as there are change needed in the worker to signal the timeout, and there is a need to keep the support for old workers. You can workaround it with a logobserver by looking at the string "command timed out:" as you can see at https://github.com/buildbot/buildbot/blob/master/worker/buildbot_worker/runprocess.py#L781 HTH Regards, Pierre Le jeu. 1 déc. 2016 à 00:25, Will Rosecrans <[email protected]> a écrit : > So, I have a step that sometimes times out. When it fails, we usually > look at a summary log and see "test XYZ failed", etc. But when there is a > timeout, the summary is empty or incomplete and we have to look at the full > log, and see that it ends with a message about the timeout, and it's kind > of a pain. and easy to miss. > > So, how do I detect that a step times out? I would like to do something > like either a step that can declare that the previous step timed out, or a > subclass of the ShellCommand step I am using to run the tests that will > change it's description based on how it failed. Unfortunately, I can't > find anything about a step that indicates clearly that the reason it failed > was a timeout rather than the shell command returned nonzero. It all just > results in "FAILED" status. What's the best way to check for it? I am > using an older Buildbot v0.8.8 because I support some older infrastsructure. > _______________________________________________ > users mailing list > [email protected] > https://lists.buildbot.net/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] https://lists.buildbot.net/mailman/listinfo/users
