[Buildbot-devel] Re: BuildBot test fails on Win32 platform.

[Brian Warner]

> Great. I'd really like to get this system running. I know there are
> other solutions, but they all seem to be Java, C# etc. I'm trying to
> keep a lid on the number of languages we use and Python is one that we
> use.

Cool.. works for me :).

I'm hoping to get a publically-visible meta-buildbot set up this week, or
next. If you've got a spare win32 machine that could run a slave, we could
probably keep the win32 compatibility problems down in the future. (the
buildslave that runs the win32 twisted testsuite might also be available for
buildbot work, but when there a problems it helps to have a highly-motivated
person at the other end :).

> I think that is working fine now. I haven't run any of the VC tests as
> we are using Perforce and Alienbrain. The other tests that I'm having
> trouble with I let you know about.

Yeah, this is what I get for not reading all my mail before replying to the
first one. I'm working through the others now. My thoughts so far:


usePTY:

 the stdout-vs-stderr thing is really a PTY question. We should have two
 modes:

  usePTY=True, in which case we only expect one stream out of the command
  usePTY=False, in which case we expect separate stdout and stderr

 in the unix world, the purpose of using the PTY is to get a separate process
 group code the child command (and, more importantly, for any grand-child
 processes it might spawn). You can kill off a whole process group at once,
 so if your build or your tests have a process that hangs, the timeout will
 clean up better. The downside is that stdout and stderr are merged
 (interleaved), since both file descriptors are pointing at the same pipe.
 Sometimes it's nice to have them separated out, and the logfile displaying
 code will put them in different colors if they're there.

 Not all unix OSes handle PTYs the same, I remember having problems with
 solaris that made me need to set usePTY=False. Also, it's kind of nice to
 get separate stdout/stderr streams, so it's a tradeoff.

 Now, in the windows world, I'm not assuming the existence anything like
 process groups, so I'd be fine with setting usePTY=False all the time (in
 fact I think the code does this internally). But does windows have the
 concept of stdout vs stderr? From your message it sounds like it does.

 I'm studying your slave_win32.patch (SF#1185548) more closely before
 applying it, because I want to make sure that 1) we're testing that these
 streams are interleaved, not just appended, and 2) that it makes sense to
 have usePTY=True on windows at all.

favicon.ico:

 I'll change buildbot/status/html.py to construct buildbot_icon better.. that
 "../buildbot.png" hack certainly won't work for windows. I'll also change
 the test to let Waterfall() use the default favicon (I hadn't yet
 implemented the default when I wrote the test). Hopefully that plus the
 read-in-binary change will fix the test.

web_pathname_port:

 this test involves two separate listening TCP sockets: it's using a
 "web.distrib" distributed publisher. The first socket is the resource that's
 being published (and is speaking "PB", twisted's RPC protocol). The second
 socket is the actual web server, and is speaking HTTP.

 I'll add the timeout you suggested. Take a look in _trial_temp/test.log and
 see if there are any additional messages in there. The IPv4Address
 deprecation warning is ok, that's just a minor issue that should have been
 fixed in Twisted itself (and is in CVS, but not yet in any released
 versions).


cheers,
 -Brian