Closed Bug 484413 Opened 15 years ago Closed 15 years ago

move fx-win32-1.9-slave07 and 08 to production

Categories

(Release Engineering :: General, defect, P2)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: nthomas)

References

Details

Attachments

(1 file, 1 obsolete file)

These machines don't appear to be based on the win32 ref platform at all. They don't even have d: or e: drives. More importantly, they have been consistently failing to build, causing permanent bustage on the Firefox3.0 tree.
Depends on: 484414
Turns out that the two slaves having issues are physical machines. Rather than cloning new slaves we can just pull the two staging machines forward, since we don't actually use them for staging changes anymore. Adjusting summary to mach.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: -- → P2
Summary: fx-win32-1.9-slave10 and 11 need to be recloned → move fx-win32-1.9-slave07 and 08 to production
I'm removing the win2k3hw factory since it's not in use anymore and re-enabling slaves 07 and 08 to do production builds.
Attachment #368564 - Flags: review?(nthomas)
Comment on attachment 368564 [details] [diff] [review]
replace fx-win32-1.9-slave10+11 with 07+08

>-# firefox_trunk_win2k3_builder = {
>-#    'name': "WINNT 5.2 fx-win32-1.9-slave07 dep unit test",
>-#    'slavenames': ['fx-win32-1.9-slave07'],
>-#    'builddir': "trunk_2k3_7",
>-#    'factory': win2k3Factory,
>-#    'category': "Firefox",
>-#}
>-
>-#firefox_trunk_win2k3_2_builder = {
>-#    'name': "WINNT 5.2 fx-win32-1.9-slave08 dep unit test",
>-#    'slavenames': ['fx-win32-1.9-slave08'],
>-#    'builddir': "trunk_2k3_8",
>-#    'factory': win2k3Factory,
>-#    'category': "Firefox",
>-#}

I think you can just uncomment the above.

>+firefox_trunk_win2k3_builder = {
>+    'name': "WINNT 5.2 fx-win32-1.9-slave08 dep unit test",
>+    'slavenames': ['fx-win32-1.9-slave08'],
>+    'builddir': "trunk_2k3_10",
>+    'factory': win2k3FactoryHw,

This is the factory you're removing, no ?  Rest of the patch looks fine.
Attachment #368564 - Flags: review?(nthomas) → review-
Checking in master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/testing/unittest/master.cfg,v  <--  master.cfg
new revision: 1.41; previous revision: 1.40
done
Attachment #368564 - Attachment is obsolete: true
Attachment #368572 - Flags: checked‑in+ checked‑in+
Alright...those slaves are building now. Let's see how they do.
Currently red and hidden on the waterfall, taking 'cos I'm build sheriff this week.
Assignee: bhearsum → nthomas
(In reply to comment #6)
> Currently red and hidden on the waterfall, taking 'cos I'm build sheriff this
> week.

Thanks Nick.
Assignee: nthomas → bhearsum
Both these boxes have errors like

C:\WINDOWS\system32\cmd.exe /c python C:\Utilities\killAndClobberWin.py --platform=2k3 --slaveName=slave
 in dir E:\slave\trunk_2k3_7\. (timeout 1200 secs)
Traceback (most recent call last):
  File "C:\Utilities\killAndClobberWin.py", line 109, in <module>
    main(sys.argv[1:])
  File "C:\Utilities\killAndClobberWin.py", line 96, in main
    tboxCvsCo = open(tboxClobberLog)
IOError: [Errno 2] No such file or directory: 'E:\\slave\\trunk_2k3\\logs\\tbox-CLOBBER-cvsco.log'

Note the difference between the actual dif, trunk_2k3_7, and where it's looking for the log. In the interests of getting these boxes back quickly (for 3.0.8 firedrill patches), I've hacked killandClobberWin.py to append the correct _N. We should really pass the build dir to the platform argument.
Assignee: bhearsum → nthomas
Both are now unhidden on the Firefox3.0 waterfall.
These builds are mostly cycling OK. We're getting occasional exceptions due to timeouts in checkout and assorted test suites, at the rate of 3 exceptions in 17 builds since midnight march 26th.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: