ReleaseEngineering/Applications/Clobberer
Application Description
The clobberer allows developers to "clobber" particular build directories (objdirs) on particular slaves. This is sometimes necessary if a change is committed that is not compatible with previous objdirs, or occasionally when a compile failure results in a bogus objdir.
The application has an outward-facing web interface for developers, and also provides an internal web service which buildslaves contact to determine what build directories they should clobber.
There are several vhosts involved here:
- API
* http://clobberer.pvt.build.mozilla.org - production API * http://clobberer-preproduction.pvt.build.mozilla.org - preproduction API * https://api-pub-build.allizom.org/clobberer/lastclobber - staging API
- UI
* production
* http://clobberer.pub.build.mozilla.org - http 302
* https://secure.pub.build.mozilla.org/clobberer - https
* staging
* https://api-pub-build.allizom.org/clobberer
Requirements
- MySQL server (SQLite is also possible, but we are using MySQL in production and staging)
- PHP and Apache
Resources
- two MySQL databases (production and staging)
- runs on the releng web cluster
Security
Clobberer uses the LDAP username verified and supplied by Apache, with some users having slightly elevated priviledges (the ability to clobber release jobs).
Testing/Updating
Basic patch testing can be done on cruncher which has netflows open to the database server. Run clobberer's index.php from the command-line and pass parameters to the script by temporarily pasting this snippet above the first include statement:
/* if started from commandline, wrap parameters to $_POST and $_GET */
if (!isset($_SERVER["HTTP_HOST"])) {
parse_str($argv[1], $_GET);
parse_str($argv[1], $_POST);
}
And run the script like so:
$ php index.php 'branch=mozilla-inbound'
Redirect STDOUT to a file and compare before/after output and script timings to ensure your changes run as expected. Attach a patch to a bug, get review, and proceed to mana page for deployment instructions.