Closed Bug 504304 Opened 11 years ago Closed 11 years ago

Set up a VM with buildbot slave for initial mozmill testing.

Categories

(Mozilla Messaging :: Server Operations, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b4

People

(Reporter: standard8, Assigned: gozer)

References

Details

Attachments

(1 file, 1 obsolete file)

Now that we almost have the running of mozmill integrated with the build system I'd like to get a VM running tests in an automated fashion so we can a) get some automated tests going, b) check the stability of mozmill and the tests we have.

Here's what I think we need for now:

- A VM which we can modify the setup so that we can install mozmill whilst the MoCo guys are working out bug 457265 (platform probably doesn't matter, windows possibly best as most people run on that).
- Access for Standard8 via the normal methods.
- buildbot slave running on the VM.
- I think the slave should initially run a clone of the unit test set-up with the following specs/differences:
-- 1.9.1 branch
-- keep xpcshell-test and check targets (so that we have some confidence in the build)
-- rebuild-if-quiet time of 1.5 hours
-- Report to ThunderbirdTest
-- Run mozmill tests.

I need to elaborate on the running mozmill tests part in a separate comment once I figure out a bit more as to what is needed.
Attached patch Patch for buildbotcustom (obsolete) — Splinter Review
For the Mozmill step, I think we need:

- This patch against buildbotcustom's factory.py / CCUnitTestBuildFactory
- A modification in config.py & master.cfg to set up a new unittest branch (clone the existing one but add the parameter exec_mozmill_suites=True.

We'll also need the patches on bug 500142 and bug 503886 applied to the source, but I can do that once the config of the VM & builder is done.

The patch essentially reuses the xpcshell-test/check code to process the mozmill tests. It will hopefully work, but I won't be surprised if we need a couple of other changes as well. It should be a good starting point anyway ;-)
Priority: -- → P2
That's going to be momo-vm-win2k3-02. It's up and running now, as part of the regular win2k pool. Once it proves itself green a little, you can have at it.
(In reply to comment #2)
> That's going to be momo-vm-win2k3-02. It's up and running now, as part of the
> regular win2k pool. Once it proves itself green a little, you can have at it.

It is denying me access at the jump host(?) so I guess I'm not allowed to have it yet ;-)

Apart from the initial bloat failure due to no previous logs, it is fine otherwise.

One of the first things I'll be doing is installing MozillaBuild 1.4 as that has easy_install included in it (assuming there's no objections to that).
momo-vm-win2k3-02 is now off the pool and Standard8 should have jump access to it.
momo-vm-win2k3-02

mkdir /e/extras
export PYTHONDIR=/e/extras
easy_install --install-dir=/e/extras jsbridge
(installs mozmill as well)
easy_install --install-dir=/e/extras mozmill

Also downloaded jsbridge source, built with the item 2 patch from https://developer.mozilla.org/User:Sid0/Mailnews/Mozmill_on_Windows#Part_4.3a.c2.a0Patching_up_the_code and did a developer install into /e/extras.

Then applied patches from bug 500142 and bug 503886 to several builds but ended up using win32-comm-1.9.1-check.

mozmill is then run via make mozmill in the win32-comm-1.9.1-check/objdir directory.
I've run the test a few times and seen one possible failure (may have been caused by me clicking at the wrong time), however I think this is ready to roll as a "test" test box.

Buildbot set up as per comment 0 - disable clobber, also set PYTHONDIR=/e/extras
 in the environment for running mozmill (at least).
(In reply to comment #5)
> momo-vm-win2k3-02
> ...
> Also downloaded jsbridge source, built with the item 2 patch from
> https://developer.mozilla.org/User:Sid0/Mailnews/Mozmill_on_Windows#Part_4.3a.c2.a0Patching_up_the_code
> and did a developer install into /e/extras.

Just so I can reproduce/document at a later time, (and since my python-foo is limited), can you explicitely describe what you did when you 'did a developer install' into /e/extras.

Looks good otherwise.
Depends on: 505433
(In reply to comment #7)
> Just so I can reproduce/document at a later time, (and since my python-foo is
> limited), can you explicitely describe what you did when you 'did a developer
> install' into /e/extras.

export PYTHONDIR=/e/extras
svn checkout http://jsbridge.googlecode.com/svn/trunk/ jsbridge-read-only
cd jsbridge-read-only
patch -p1 < bug505433.patch
python setup.py develop --install-dir=/e/extras/
momo-vm-win2k3-02 is now connected to the staging buildbot master with the required mozmill changes, watch it here:

<http://build.mozillamessaging.com/buildbot/staging/>

and it will be reporting here:

<http://tinderbox.mozilla.org/ThunderbirdTest/>
mozmill requires NO_EM_RESTART to not be set, so ensure that is the case when running make mozmill.
Attachment #388693 - Attachment is obsolete: true
Attachment #391143 - Flags: review?(bhearsum)
Attachment #391143 - Flags: review?(bhearsum) → review+
Comment on attachment 391143 [details] [diff] [review]
[checked in] Patch for buildbotcustom v2

comparing with ssh://hg.mozilla.org/build/buildbotcustom
searching for changes
changeset:   370:43ad88816605
tag:         tip
user:        Philippe M. Chiasson <gozer@mozillamessaging.com>
date:        Thu Jul 30 15:16:41 2009 -0400
summary:     Bug 504304. Add mozmill support to CCUnittestBuildFactory. r=bhearsum
Attachment #391143 - Attachment description: Patch for buildbotcustom v2 → [checked in] Patch for buildbotcustom v2
This has now been set up and is running on the ThunderbirdTest tree for stability assessment.

Once we've run it for a while, we'll raise new bugs for formalising the last few bits and spreading it across all the builders.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b4
You need to log in before you can comment on or make changes to this bug.