Sometimes, buildbot fails to clean working copy.

/////////////////////////////////////////////

(snip)
Clean started: Project: _hashlib, Configuration: Debug|Win32
Deleting intermediate and output files for project '_hashlib', configuration 'Debug|Win32'
_hashlib : error PRJ0008 : Could not delete file 'c:\buildslave\2.7.moore-windows\build\PCbuild\_hashlib_d.pyd'.
Make sure that the file is not open by another process and is not write-protected.
_hashlib - 1 error(s), 0 warning(s)

Build complete: 8 Projects succeeded, 17 Projects failed, 1 Projects skipped

/////////////////////////////////////////////

This might cause checkout error next time. Maybe attached
patch can improve this situation. Thanks.

I wonder if it might be better to have kill_python run at the tail end of test.bat, since there's a potential window where losing a connection to the build master might not run the clean step, so still risk blocking a future build after a reconnect due to still running processes.

As far as I can tell, the same change also needs to be done in build-amd64.bat and clean-amd64.bat.

By the way, the order of these lines in clean-amd64.bat looks wrong:

cd PCbuild
@echo Deleting .pyc/.pyo files ...
del /s Lib\.pyc Lib\.pyo

Oh, and the regrtest command line in test-amd64.bat lacks some options ("-rwW -n") compared to test.bat.

Probably - it's just a general sequencing change, so I suppose should apply equally to all platforms. I suppose even better would be to consolidate the two clean scripts into one (with a parameter for 32 v. 64), but just patching both is less of a change. Unrelated, but it's interesting how the amd64 script makes sure to be in the PCBuild tree before deleting byte compiled files, but the standard script doesn't.

Oh, I should probably also update my prior thought in this ticket, since based on a python-dev thread Hirokazu pointed out that just having things at the end of test.bat could be exposed if the actual test itself never returns to the script.

That might have higher odds than the build master losing contact with the slave between build and clean step, so the original patch is likely the better choice. Or maybe do it in both both places.

But just moving things to clean first would cover the vast majority of cases I seem to see on my build slaves, which only rarely lose contact with the master.

@Steve I'm assuming that this is covered by the work you're doing for 3.5 builds, am I correct?

Probably, but that work is not going to be checked in for a while (until we have guarantees that we'll be able to use VC14 and there's a 'go-live' version available). If this is causing problems now, it should be fixed.

The patch looks fine to me, but Zachary Ware does more of the buildbot script maintenance (not sure if I can nosy him without being able to log in...)

Sent from my Windows Phone

From: Mark Lawrence<mailto:report@bugs.python.org>
Sent: ‎6/‎27/‎2014 9:39
To: Steve Dower<mailto:Steve.Dower@microsoft.com>
Subject: [bpo-9973] Sometimes buildbot fails to cleanup working copy

Mark Lawrence added the comment:

@Steve I'm assuming that this is covered by the work you're doing for 3.5 builds, am I correct?

----------
components: +Windows
nosy: +BreamoreBoy, steve.dower
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue9973\>

The real simple method here would be to replace clean[-amd64].bat with a call to kill_python_d (if it exists), followed by an "hg --config extensions.purge= purge --all". That ought to give as much of a guarantee of a clean slate as possible, with the added benefit of hg purge reporting files that it just can't remove.

This should be fixed by bpo-21907 for 3.5, at least; other versions can either have bpo-21907 backported (in whole or in part), or continue to live with it (like they have for the past 4 years).