Leeroy is the Jenkins job that executes each project. Dozens of Leeroy jobs are started in parallel, and the build_jenkins.py polls for their completion before starting unblocked projects in the completion graph. Why name it Leeroy? A mesa dev thought of Leeroy Jenkins and wanted a reference to the meme in the CI.
The most important design consideration for the Mesa CI is to minimize configuration in Jenkins. Editing Jenkins jobs in the web UI is error prone, doesn't support branches, and doesn't generate a history. Many CI projects show early promise, but fail as the system grows in complexity, due to the lack of good SCM in the CI tools domain. Without decent SCM, features cannot be tested before rollout, or rolled back when issues are encountered.
To accomodate this limitation, Mesa CI:
keeps all automation in git
allows branches of the automation to be specified as a parameter to the Jenkins jobs
limits complexity of jenkins jobs to checking out the sources, and invoking the automation.
A couple of odd items about Leeroy:
some test suites require X. Chad Versace is attempting to change them to use GBM upstream. For now, X is launched whenever hardware is not "builder" (builders don't run graphical tests) and killed afterwards.
builders are generally Xeon servers which run many jobs in parallel. To simplify build configuration, all automation builds and installs to /tmp/build_root -- which will clash for CI jobs. For this reason, Leeroy uses a mount namespace to give each job a private directory at that path. This occurs when hardware is "builder". It used to use a mount namespace for every job, but updates to debian prevented processes in the namespace from accessing X.
Aside from Leeroy, most other jobs in the CI simply schedule Leeroy jobs. Top-level jobs like mesa_master or developer builds check out sources, and invoke scripts/build_jenkins.py. This script generates a dependency graph and start parallel Leeroy jobs as defined in the build_specification.
Because of the limited complexity of Leeroy, any CI infrastructure (eg BuildBot) could readily be used to implement Mesa CI. build_jenkins.py could be reimplemented to trigger and wait for jobs on aprbitrary CI infrastructure.