Molly buildmaster

timfernando edited this page Nov 9, 2011 · 6 revisions

The Molly buildmaster is a virtual machine donated by the Mobile Oxford team and hosted at Oxford University Computing Services - It runs our buildbot master, and one of the slaves on the same machine. The mollydemo slave controls, another machine donated by OUCS.

Also on this server runs the JIRA instance - This machine is backed up to OUCS's HFS service.

The buildbot config is version controlled here:, but there is no automatic updating.

To update buildbot, someone with SSH access on that machine (currently Tim Fernando) will have to SSH in and then:

  • sudo su - builder
  • cd /srv/buildbot
  • source virtualenv/bin/activate
  • cd master
  • git pull
  • buildbot restart /srv/buildbot/master

Also on this machine, there is:

Eggdrop (IRC Bot)

(in /home/chris/eggdrop - although Chris Northwood no longer has access to this machine) which simply logs to /srv/docs/irclogs -

  • sudo su - chris
  • ~/eggdrop/eggdrop


To startup:

  • sudo su - jira
  • env FISHEYE_INST=/var/fisheye /opt/fisheye/bin/


To startup:

  • sudo su - jira
  • /opt/jira/bin/

Other tools

  • /srv/molly - the Molly instance for unit testing
  • /srv/molly-local - the minimal Molly site used for unit testing
  • /srv/docs - this is the output of the documentation generation process and served at
  • /srv/reports - this is the Pylint and unit test coverage reports generated as part of the continuous integration builder and are exposed at
  • /srv/data - this contains any data used by the buildmaster which slaves can download. Atm, it's only the figleaf-exclude file which contains the files which figleaf should ignore when computing code coverage
  • /srv/apks - this stores the APKs built by the Android continuous integration system and are exposed at

Documentation Generation

The script here ( is called as part of the continuous integration process. The first argument is the folder where output should be saved to (this is /srv/docs on buildmaster) and the second is the Python executable to use (used to make sure epydoc, etc, happens inside the virtualenv, and Molly can be found for autodoc).

This takes the current checkout and saves the built docs in a folder called 'dev', and then checks out all tags, and then saves the built docs in folders matching their tag names. Epydoc is also run over each tag and master in a similar way, this time under a folder called 'api' in the output folder.

Once this is complete someone will have to add a link to the tag in /srv/docs/index.html (and perhaps change the current stable release) to make it visible from the website.

On the mollydemo machine, there is a slave in /srv/buildbot, the Molly install in /srv/molly and the demo site config in /srv/molly-local.