On Sat, Jan 19, 2013 at 3:42 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Hi Jim,
This is an example of the Windows problem I was referring to:
http://jenkins.simplistix.co.uk/job/testfixtures-buildout/160/PYTHON=2.5,lab...
C:\Python25\python.exe bootstrap.py
...appears to fork off a process in such a way that it returns instantly and then runs in the background. Of course, Jenkins has no way to know how long to wait for, so problems such as those above occur.
My horrible hack around this is:
https://github.com/Simplistix/testfixtures/blob/master/jenkins.bat#L2
...which waits 20 seconds and then moves to the next step. It's far from reliable, especially when the Windows box has any load on it.
Can you make any suggestions how to solve this problem?
No, can you? :) The problem is that buildout is upgrading for a new setuptools. To do this, it needs to rewrite the buildout script, but *windows* won't let it do that because the script is open. Maybe there's a better way around this. Your workaround, if I understand it, to wait 20 seconds looks good to me. :) Another option would be to pin setuptools in your buildout.cfg to avoid the upgrade.
PS: Where does the buildout continuous integration testing live nowadays?
https://travis-ci.org/buildout/buildout Unfortunately, the buildout2 tests always fail there, even when they pass for me. I didn't set those up and I'm not sure what's going on with them. http://winbot.zope.org/builders/ Note that the buildout 1 tests always fail. (I give up.) and buildout 2 doesn't buildout on Python 3 on Windows. The buildout 2 failure looks spurious. I typically clean up the windows test failures (if I think of it) before making a release. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm