Sheriffing/TBPL/DeveloperDocs

About the service

Overview / basic idea

In one sentence, TBPL shows Firefox developers what is happening in their repositories.

Every checkin to a Firefox repository triggers the execution of several automated test jobs for the new revision. For each push the new source is compiled to a fresh binary on all supported platforms, and the resulting binaries are then tested by lots of automated unit and performance tests.

TBPL shows a repository's state by correlating pushes (checkins) with the results of these automated jobs. For each push, the corresponding changesets (code changes) are listed in the left half of the page, and the triggered jobs are listed in the right half of the page. Every job (also called "build" and "run") is represented by one colored letter. The color of each letter depends on the success status of the job.

Developers need to make sure that their changes don't "break the tree", i.e. that they don't cause any tests to fail, so they'll usually monitor TBPL for a while after they've checked in.

Further functionality

On top of the basic functionality, TBPL has these features:

• Clicking on a job shows details of the job result in a pane at the bottom. Job details include:
  • Exact numbers of passed / failed / skipped tests, or performance numbers for performance tests
  • Links to the job's log (in abridged and full form)
  • For unsuccessful jobs, an excerpt of the log that only lists failures ("blue box", "summary")
  • Comments on the job ("yellow box", "stars")
• From the job details panel, the user can perform actions on the job:
  • Comment on the job ("star it")
  • Restart the job (for example to get more performance data, or to see if a test failure is intermittent)
  • Cancel the job, if it hasn't finished yet
• more

Development documentation

There is no design doc for development. Development happens in the repository at http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/ and in the Bugzilla component Webtools : Tinderboxpushlog.

Installation instructions are given in the README file.

TBPL doesn't have versions or milestones. Changes are usually implemented in response to a bug in Bugzilla (see list of open bugs) and deployed as they come in. The motivation behind specific parts of the code can be figured out by looking at the hg annotate of the file and tracing it back to the bug where the code was landed.

Hardware

(what is going to be used here, physically?)

OS

(self explanatory, note any exceptions)

Network flows

(firewall needs?)

Load Balancing / Caching Load balancing

(round robin? VIP? GLB?)

Health checks

(how will the app be checked for validity from the lb?)

Front end caching

(http caching)

Back end caching

(memcache etc)

Database

(what database server(s) - rw & ro, db name(s), db username) Other requirements

(sphinx, redis, celery, etc)

Tbpl currently uses a read-write MongoDB database, configured to use the default settings (localhost:27017)

File storage

(internally or externally mounted filesystems.. where will static data for this service live?)

Automation

Cron jobs

(if the cron jobs run from an admin machine, please specify where they will run)

Puppet

(what modules/classes will be used?)

Monitoring

Nagios

(what checks will need set for this service?)

Ganglia Update / Push procedure

(how to update the code, db, etc)

Backup / DR

(where are backups stored if any?

How can someone else fix this site in a disaster?)

Admin Contacts

Primary Admin:

Secondary Admin: