If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Only do win64 builds on mozilla-central



Release Engineering
6 years ago
4 years ago


(Reporter: philor, Assigned: armenzg)


Firefox Tracking Flags

(Not tracked)




6 years ago
I've spent a fair bit of the day today in admintree.cgi on various and sundry trees, hiding Win7 x64 builds (which fail in utterly random jit-tests) and Win7 x64 tests, which fail multiple test suites because the Win7 x64 slaves have old drivers on which we don't support hardware acceleration, but our tests assume we don't run tests on broken slaves.

Supporting building and testing on Win7 x64 is a fine thing to do, and I'll be happy to help with getting it going, but until we actually do, we need to STOP RUNNING IT. We need to stop running it on mozilla-central, and we sure as shooting need to stop running it on whatever random branch the builder happens to decide it would be fun to build. Mozilla-Inbound doesn't need baffling orange builds and tests. Services-Central doesn't need baffling orange builds and tests. Whatever branch it will choose next doesn't need baffling orange builds and tests.

Please shut off mw64-ix-slave01 until we're actually ready to have a production Win7 x64 builder.
Disabled (buildbot.tac moved, since it's not in slavealloc) and rebooted.

Comment 2

6 years ago
Since I hear that the nature of my objections wasn't quite clear:

* My biggest objection of all is that it is building on random branches (at least Places, Services-Central and Mozilla-Inbound that I know of), where since we default to scrape and unhidden, it's a suddenly-visible four-permaorange mystery. I can't like it running hidden on mozilla-central, but I was living with it. Having it cause orange on random branches I cannot live with.

* My second biggest objection is that it is not our usual "running this new platform hidden while we fix up the code problems that make it orange," but instead is orange because the win64 ref image lacks sufficiently new drivers to get hardware acceleration.
Severity: blocker → normal
philor was OK to re-enable win64 builds to for m-c only, since the builds are already hidden appropriately there. So I've made these changes in staging-master:/builds/buildbot/builder_master4/:
* to limit the branches & projects being run, in production_armen.py: set
   ACTIVE_BRANCHES = ['mozilla-central']
  instead of
   ACTIVE_BRANCHES = ['mozilla-central'] + PROJECT_BRANCHES
* to limit the platforms being run, in config.py added:
    BRANCHES = {
      'mozilla-central': {
   +        'lock_platforms': True,
   +        'platforms': {
   +            'win64': {},
   +        }
 and commented out 
   BRANCHES['mozilla-central']['enable_weekly_bundle'] = True
   BRANCHES['mozilla-central']['platforms']['linux-rpm']['enable_nightly'] = True
   BRANCHES['mozilla-central']['platforms']['linux64-rpm']['enable_nightly'] = True
   BRANCHES['mozilla-central']['platforms']['linux-android']['env']['MOZ_SYMBOLS_EXTRA_BUILDID'] = 'mozilla-central'

Disabling the bundling config prevents a staging box uploading bundles over the top of production files. The list of builders is now:
 WINNT 6.1 x86-64 mozilla-central build
 WINNT 6.1 x86-64 mozilla-central nightly
 WINNT 6.1 x86-64 mozilla-central xulrunner
and I have reconnected mw64-ix-slave01.
Last Resolved: 6 years ago
Resolution: --- → FIXED
Summary: Turn off mw64-ix-slave01. Just turn it off. → Only do win64 builds on mozilla-central

Comment 4

6 years ago
Thanks dustin, nthomas.

Comment 5

6 years ago
Resolution: FIXED → ---


6 years ago
Assignee: nobody → armenzg

Comment 6

6 years ago
I have to fix in production rather than have it on a local setup. *sigh*
Sorry philor.
Depends on: 656995


6 years ago
Priority: -- → P2

Comment 7

6 years ago
I am moving the slave from the staging master to the production master and will only be building for mozilla-central until we have more slaves.

See bug 656995 for more details.
Last Resolved: 6 years ago6 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.