[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. 
:P

Aaron




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

To
Aaron Hsieh/R&D/SCEA at PLAYSTATION
cc
buildbot-devel at lists.sourceforge.net
Subject
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?

Dustin

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 
have
> no output for a very long time, and these run times are only getting 
longer
> as we add more tests to the script.  We could add a verbose mode, but 
that
> would serve as a double-edged sword since it would cause our developers 
to
> completely ignore our logs altogether if we try to get too verbose with 
our
> tests.  So, instead, I implemented a little hack-y way to disable the
> timeout option if needed in a master configuration file.  This patch 
would
> 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, 
self.doTimeout)
> +           if self.timeout < 0:
> +               pass
> +           else:
> +               self.timer = reactor.callLater(self.timeout, 
self.doTimeout)
>
>          for w in self.logFileWatchers:
>              w.start()
>
>
> Again, this is probably not the best way to do it, but it's the best I 
could
> 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 
have,
> and keep it there for as long as needed.  If I ever want to restore the 
old
> timeout, it's as simple as removing the "-" from the existing timeout. 
It's
> 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
http://www.zmanda.com


-------------- 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