Servo continuous integration is run on a segregated set of machines within the RelEng network. Servo's CI system is different than the bulk of our infrastructure, and revolves around Bors for testing and merging of Github Pull Requests.
Servo has its own PuppetAgain Organization and as such it has its own Puppetmaster, servo-puppet1.srv.servo.releng.use1.mozilla.com. Servo also has its own Buildbot master and slaves. Search for "servo" on Inventory to find the complete list.
Unlike most of the rest of RelEng systems, "servobld" is the primary account on these (instead of "cltbld").
Bors is the driving force behind Servo's CI system. It is script that runs through cron that looks for open pull requests on the Servo github repository, runs builds and tests on them, and merges them if they pass. It's important to note that Bors only handles one pull request at a time. For example, while pull request A is being tested, no other requests are processed. It does this to avoid untested combinations of patches landing at the same time.
Bors runs on Servo's Buildbot master and is deployed with a PuppetAgain module. It uses the dedicated github account "bors-servo" to talk with Github. Both RelEng and some Servo developers have the credentials for this account.
Servo's Buildbot Master runs the latest version of Buildbot (at the time of writing - 0.8.7p1) and uses a simple master.cfg that lives in the PuppetAgain repository.
Despite being segregated from the rest of the RelEng pool, Servo's slaves are set-up exactly the same as their main pool counterparts. They sync against PuppetAgain and run the exact same manifests.