607910 - [SeaMonkey 2.0, Windows] Packaged tests are not run anymore

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, defect)

Description

[Serge Gautherie (:sgautherie)]

Since at least 2010/09/17 :-(

Comment 1

[Serge Gautherie (:sgautherie)]

I checked config.py but didn't notice anything unexpected there.
I have no clue.

Comment 2

[Robert Kaiser]

The columns are there on the buildbot waterfall, I guess they are not triggered any more though.

Comment 3

[Robert Kaiser]

WINNT 5.2 comm-1.9.1 unit test: steps/sendchange/logs/stdio has

python /e/builds/slave/comm-1.9.1-win32-unittest/tools/buildfarm/utils/retry.py -s 5 -t 1800 -r 5 --stdout-regexp change sent successfully buildbot sendchange --master cb-seamonkey-linuxmaster-01.mozilla.org:9010 --username sendchange-unittest --branch comm-1.9.1-win32-unittest --revision None http://stage.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-1.9.1-win32-unittest/1288252726/seamonkey-2.0.10pre.en-US.win32.zip
 in dir e:\builds\slave\comm-1.9.1-win32-unittest\build (timeout 1200 secs)
 [...]python: can't open file '/e/builds/slave/comm-1.9.1-win32-unittest/tools/buildfarm/utils/retry.py': [Errno 2] No such file or directory
program finished with exit code 2

Comment 4

[Robert Kaiser]

I tried to solve this with http://hg.mozilla.org/build/buildbotcustom/rev/559708821cb9

Comment 5

[Robert Kaiser]

Attachment: move the toolsdir override

For correctness, seeking review for this patch. The reason it should help is because the path we call retry.py with only differs to the debug builds that invoke them on trunk by the working ones having a leading "e:" while the failing ones have a leading "/e/" in the path, so I guess we need the difference right in that sendchange call inside the upload diff (last thing to be invoked there) but we only rewrite it to be Windows-style right after this. The patch moves it to be before that, which actually matches what the original UnittestBuildFactory is doing.

Comment 6

[Robert Kaiser]

(In reply to comment #4)
> I tried to solve this with
> http://hg.mozilla.org/build/buildbotcustom/rev/559708821cb9

This on the buildbot-0.7 branch and applied to our master has solved the original bug, but I'll only mark this fixed once this has reviews and landed on the default branch.

Comment 7

[Robert Kaiser]

Thanks, checked in on default branch as http://hg.mozilla.org/build/buildbotcustom/rev/9e536c53028b