[Buildbot-devel] Increase Timeout value for master

Aaron_Hsieh at PlayStation.Sony.Com Aaron_Hsieh at PlayStation.Sony.Com
Tue Feb 12 20:13:51 UTC 2008

Hmm, after looking further into the code, it appears that most of my patch 
is unneeded after all.  The ShellCommand class actually does support 
timeout=None, which makes that specific step not timeout at all.  And here 
I was thinking I was so clever in making this little hack which turned out 
to be a redundant effort in the end. :P

Although, this patch does make it easier to reverse the timeout disabling 
process if needed.  But, I guess if someone predicts that this kind of 
change would be reverted in the future, he would simply backup the master 
config file instead of using this patch.  Sorry about the useless patch. 


"Dustin J. Mitchell" <dustin at zmanda.com> 
Sent by: djmitche at gmail.com
02/12/2008 11:37 AM

buildbot-devel at lists.sourceforge.net
Re: [Buildbot-devel] Increase Timeout value for master

That's not so much of a hack after all!  With the addition of a test
case and some documentation, I think this would make a good addition
to buildbot.  Aaron, do you want to revise?


On Feb 12, 2008 2:21 PM,  <Aaron_Hsieh at playstation.sony.com> wrote:
> I've also had this problem where some of the scripts that my group runs 
> no output for a very long time, and these run times are only getting 
> as we add more tests to the script.  We could add a verbose mode, but 
> would serve as a double-edged sword since it would cause our developers 
> completely ignore our logs altogether if we try to get too verbose with 
> tests.  So, instead, I implemented a little hack-y way to disable the
> timeout option if needed in a master configuration file.  This patch 
> have to be done on the slave side to work though:
> --- slave/commands_bak.py       2008-02-12 11:08:24.000000000 -0800
> +++ slave/commands.py   2008-02-12 11:09:50.000000000 -0800
> @@ -336,7 +336,10 @@
>          # then comes the secondary information
>          msg = " in dir %s" % (self.workdir,)
>          if self.timeout:
> -            msg += " (timeout %d secs)" % (self.timeout,)
> +           if self.timeout < 0:
> +               msg += " (no timeout)"
> +           else:
> +               msg += " (timeout %d secs)" % (self.timeout,)
>          log.msg(" " + msg)
>          self.sendStatus({'header': msg+"\n"})
> @@ -385,7 +388,10 @@
>          # which would let us connect stdin to /dev/null .
>          if self.timeout:
> -            self.timer = reactor.callLater(self.timeout, 
> +           if self.timeout < 0:
> +               pass
> +           else:
> +               self.timer = reactor.callLater(self.timeout, 
>          for w in self.logFileWatchers:
>              w.start()
> Again, this is probably not the best way to do it, but it's the best I 
> come up with given the time I had to work on this.
> What I usually do with this is if I only wanted to temporarily disable a
> timeout, I would throw in a "-" in front of an existing timeout that I 
> and keep it there for as long as needed.  If I ever want to restore the 
> timeout, it's as simple as removing the "-" from the existing timeout. 
> nothing fancy, but I thought I would like to share this little hack I've
> been using for a bit.
> Aaron
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel

Storage Software Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20080212/6c479e78/attachment.html>

More information about the devel mailing list