We do some automatic testing of the Xen hypervisor and tools branches. These tests form the “push gate” between the “staging” branch of xen-unstable (and the stable releases) and the non-staging branches.
Changes are committed to non-staging, and if the tests pass, the test system pushes them through to staging. So if a commit breaks one of the tests, the contributors don’t get to see their changes pushed and that tends of focus minds on fixing or reverting the problem commits. There’s also a cross-repository bisector which tries to automatically pin down which specific changeset is causing trouble.
I’ve been doing some work recently to disentangle this test system, which we now call “osstest”, from its supporting infrastructure. It’s now possible to use it standalone – for example, to reproduce failures which the test system has spotted, or to write new test cases.