Auto-tools/Projects/MozmillBuildbot

From MozillaWiki
Jump to navigation Jump to search

This page documents the work from https://bugzilla.mozilla.org/show_bug.cgi?id=516984 : Run Mozmill Tests with buildbot

This is an Auto-tools project and a Q2 goal


Accomplished Work

To do

short term priorities

  • make a fresh set of patches from the Mozilla base repositories and existing work. Wipe existing http://k0s.org/mozilla/hg patch directories and recreate these. Set up a sane work strategy with mercurial queues and patch management and document this strategy. Link to these patches from this page.

Outstanding Issues

  • Running mozmill does not work as expected. This is shown in the buildbot step as well as reproducible from the command line following the build.
> /home/jhammel/mozilla/src/buildbot/slave/full/mozmill/bin/mozmill --showall -b firefox/firefox -t mozmill-tests/firefox --showall
(firefox-bin:13024): GLib-WARNING **: g_set_prgname() called multiple times
(firefox-bin:13024): GLib-WARNING **: g_set_prgname() called multiple times
Traceback (most recent call last):
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/bin/mozmill", line 8, in <module>
   load_entry_point('mozmill==1.4', 'console_scripts', 'mozmill')()
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/lib/python2.6/site-packages/mozmill-1.4-py2.6.egg/mozmill/__init__.py", line 541, in cli
   CLI().run()
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/lib/python2.6/site-packages/mozmill-1.4-py2.6.egg/mozmill/__init__.py", line 518, in run
   self._run()
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/lib/python2.6/site-packages/mozmill-1.4-py2.6.egg/mozmill/__init__.py", line 468, in _run
   self.mozmill.start(runner=runner, profile=runner.profile)
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/lib/python2.6/site-packages/mozmill-1.4-py2.6.egg/mozmill/__init__.py", line 162, in start
   self.create_network()
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/lib/python2.6/site-packages/mozmill-1.4-py2.6.egg/mozmill/__init__.py", line 142, in create_network
   self.jsbridge_port)
 File "/home/jhammel/mozilla/src/buildbot/slave/full/mozmill/lib/python2.6/site-packages/jsbridge-2.3.4-py2.6.egg/jsbridge/__init__.py", line 72, in wait_and_create_network
   raise Exception("Sorry, cannot connect to jsbridge extension")
Exception: Sorry, cannot connect to jsbridge extension

The command (mozmill -b /home/jhammel/bin/firefox -t /home/jhammel/mozilla/src/buildbot/slave/full/build/mozmill-tests/firefox --showall) works on Firefox 3.6.2 but not on on 3.7.a{4,5}pre. This is due to the maxversion checking in mozmill and jsbridge. Manually changing the files produces a working mozmill. This will be fixed when mozmill 1.4.1 comes out later this week.

  • virtualenv has trouble on the CentOS machines.

How Buildbot Works

notes from integrating the MozmillFactory

Resources

Buildbot:


Mozmill:

Tips

  • buildbotcustom is not a python package. On the VM, it is installed in /tools/buildbotcustom/buildbotcustom which is added on cltbld login to PYTHONPATH. On a local machine, I use a [1] to isolate python development. I download buildbotcustom to $VIRTUAL_ENV/buildbotcustom/buildbotcustom and then add $VIRTUAL_ENV/buildbotcustom to the PYTHONPATH in the $VIRTUAL_ENV/bin/activate file so that the code is available within the virtualenv.
  • forcing builds through the web does not work. This is due to the fact that the build and the crashsymbols are downloaded must be downloaded from the tinderbox builds so the location of the desired build is unknown as they are indexed by time stamps (seconds since epoch). buildbot sendchange should instead be used to trigger a build for testing purposes.

Outstanding Work

  • Add corrections to https://wiki.mozilla.org/Buildbot and linked pages. First this page should be finished (presumedly near project completion) and then the both pages audited to figure out what needs to be done.


Long-term Recommendations

These recommendations are hereby recorded for future use. Their need should be assessed before filed as bugs and made actionable. These are not blockers for this body of work and will not be worked on as part of it.

  • Use templates for buildbot-configs: the configurations in http://hg.mozilla.org/build/buildbot-configs are hard-coded for the setup for VMs. Instead, they could be made templates for easy deployment. Cleanup should also be done so that the configurations are more universal and adding new configurations is easy.
  • Make buildbotcustom a python package: reason: there's no reason not to (except legacy reasons, continue reading) and having the python be installable saves the trouble with messing with the PYTHONPATH. There is a considerable downside in practical terms, however; http://hg.mozilla.org/build/buildbotcustom is a top level repository; all files therein would have to be moved to http://hg.mozilla.org/build/buildbotcustom/buildbotcustom with the top level directory containing a setup.py file. While the effort is minimal, it may cause issues for existing installations which, while easily resolvable, might involve some work.
  • Allow force build through the web: several factories, including the MozmillFactory, use a buildstep like:
       def get_fileURL(build):
           fileURL = build.source.changes[-1].files[0]
           build.setProperty('fileURL', fileURL, 'DownloadFile')
           return fileURL
       self.addStep(DownloadFile(
        url_fn=get_fileURL,
        filename_property='build_filename',
        haltOnFailure=True,
        name="download_build",
       ))

However, for the case of TTW force builds, build.source.changes is an empty tuple, so the step fails with an exception. In general, if build.source.changes is empty, a URL should be constructed from the platform and other variables appropriate to the build

  • Make a paster template for buildbot testing: As a generalization, the production buildbot configs are less appropriate for testing and developing Mozilla's buildbot. A template could be created to make it easier to make testing master and slave instances. Files should include master.cfg, a forcebuild script for the buildslave, and a script for (re)starting both master and slave and forcing a build. The template additionally serves as instructions for future generations.